AIIMS Delhi Website Ad Injection: A Historical Third-Party JavaScript Case Study

The official website of AIIMS Delhi included a free visitor counter in its footer. The counter was not a static image: it was a script loaded from the counter provider's server, counter.websiteout.net, and it ran with the same access to the page as AIIMS's own code.

On 25 December 2022, Isrg Rajan reported finding advertising on the site that the institution had not placed there. He traced it to the counter, wrote to the Director of AIIMS describing the risk and the source, and offered help with removal. His findings were published on 21 January 2023, and the article reports that the AIIMS IT Cell removed the component.

For this case study we re-examined the evidence using archived copies held by the Internet Archive. The archives independently confirm the counter's presence on the AIIMS site, the content of the ad-inserting script, the match between its advertising account and the operator's ads.txt file, and the counter's disappearance from the site in late January 2023.

The evidence supports a narrower description than the original headline. This was unwanted advertising injected by a third-party script that the website had itself included. It was not an infection of AIIMS servers, adware installed on visitors' devices, or a software vulnerability in the usual sense. The risk was real nonetheless: any external script can change what a trusted public website shows its visitors, and this one did.

Hit counters were a common feature of institutional websites. Many free counter services work by embedding a small image, but some ask the site owner to embed a <script> tag. A script delivered from another domain is not isolated from the page that includes it. It can read and change the page's content (the DOM), add new elements and load further scripts, and the browser treats all of this as the website's own behaviour.

That is the core of third-party JavaScript risk. The site owner reviews the snippet once, but the code that actually runs is whatever the provider's server returns on each request, and the provider can change it at any time without the site owner's knowledge.

The original report used the word "adware". Several related terms are often used loosely, so it helps to be precise about which of them apply here.

Terminology and whether it applies to this case

Separate incident. The original article opens with background about the ransomware attack that disrupted AIIMS systems in late 2022. That incident is not part of this case study. No evidence links the visitor counter to the ransomware attack, and this research neither discovered nor remediated it.

The original article, published 21 January 2023 under the byline Registrar Bureau, documents the following findings. The next section sets out which of them are confirmed by archived evidence.

• The site aiims.edu used a third-party hit counter from websiteout.net.
• The counter loaded an image from counter.websiteout.net/compte.php, with the AIIMS hostname and a counter ID in the query string.
• It also loaded a script, counter.websiteout.net/close-firstchild.js, which the author described as able to add and load content on the host site. An archived copy was cited.
• A screenshot showed an advertisement above the AIIMS Delhi header, captioned as an ad injected by websiteout.net.
• The ads used Google AdSense publisher ID pub-5486891678306037, the same ID listed in websiteout.net/ads.txt. An archived copy was cited.
• websiteout.net redirected to websiteout.ca, and archived WHOIS records were cited to link the two domains.
• The investigator wrote to the Director of AIIMS, explaining the risks, identifying the source and offering a solution and help to the AIIMS IT Cell.
• The AIIMS IT Cell then removed the component.

The observations below come from archived copies of the files, read as plain text, and from the Internet Archive's capture index. No historical script was executed, and AIIMS's current systems were not accessed or tested.

How the counter was embedded

Archived copies of aiims.edu/en.html show the counter in the site footer, next to the text "You are Visitor No.", as a script tag loading //counter.websiteout.net/js/30/10/22368976/0. The embed is absent from the January 2018 capture we checked and present in captures from January 2019 through 12 January 2023. The original report describes close-firstchild.js and compte.php, which are loaded by this script rather than embedded directly.

Two versions of the same script

The Internet Archive holds many captures of the counter URL from 2022. They contain two distinct responses. One is about 220 bytes and does only what a counter should: it writes a link and the counter image. The other is about 2.7 KB, begins with the same counter code, and then inserts advertising. Captures of both versions appear throughout 2022, sometimes days apart. The archives do not show why the server returned one or the other. It may have depended on the requester, timing or other conditions.

This matters for anyone assessing third-party code. A one-off review of the URL could easily have returned the harmless version.

What the ad-inserting version does

Behaviour of the ad-inserting counter script (capture of 20 December 2022)

window.onload=null;
xx=doc.getElementsByTagName("iframe");
if (xx.length) xx[0].parentNode.removeChild(xx[0]);
removeByClassName("adsbygoogle");
…
doc.write('<div id="ChromeBrowser" style="position:fixed;top:0px;left:0px;width:750px;…;z-index:2147483644;">');
google_ad_client = "ca-pub-5486891678306037"; …
… src="//pagead2.googlesyndication.com/pagead/show_ads.js" …
… src="//counter.websiteout.net/close-firstchild.js" …

Abridged excerpt of the ad-inserting version (archived 20 December 2022). Lines not needed to understand the behaviour are omitted, and split string concatenations are joined for readability.

The role of close-firstchild.js

The archived copy of close-firstchild.js cited by the original report (captured 28 December 2022) is short. It closes an open div, moves the element with ID ChromeBrowser to the beginning of the page body, and after one second repeats the move and calls a helper to remove further elements by class name. The helper is defined in the counter script, not in this file. On its own, the file repositions an element. The advertising is created by the counter script that loads it.

Comparing captures shows the container was renamed between 28 November and 20 December 2022 from the meaningless ggoggo to ChromeBrowser, and close-firstchild.js was updated to match. Apart from that rename, the 2018 and 2022 versions of close-firstchild.js are functionally identical, which suggests the mechanism existed long before the report. The archives do not show when the ad-inserting version was first served to the AIIMS site.

Corroborating details

• The screenshot in the original report shows a banner advertisement, with ad-choice and close controls, above the AIIMS Delhi header at aiims.edu/en.html. This matches the fixed top-left placement in the code.
• The archived websiteout.net/ads.txt (1 January 2023) contains a single line authorising Google publisher pub-5486891678306037, the account named in the script.
• WebsiteOut's current website describes a French web-hosting business operating since 1999 and mentions visitor counters among its offerings. We could not locate the terms that applied to its free counter in 2022, so we cannot say whether advertising was disclosed to counter users.

What the archived code does not show

The archived files show no exploit code, credential or form capture, file downloads, cryptocurrency mining or automatic redirection of visitors. The specific advertisements served through AdSense are chosen dynamically and are not preserved, so their content cannot be assessed beyond the one ad in the original screenshot, which promoted an online teaching platform.

We separate what the evidence shows from what can reasonably be inferred from it.

Observed facts compared with inferred risks

Was the script malicious?

That depends on the definition. The code inserted unrequested advertising into a host site, removed the host's own elements and earned revenue from the host's traffic. Most site owners would treat that as abusive, and it was unacceptable on an official healthcare website. However, the archived code does not attack visitors' devices or data, and we found nothing to show that the operator used the access more harmfully. We therefore describe it as unwanted ad injection by a third-party script, not as malware.

Why the risk was serious anyway

The concern is the capability as much as the observed behaviour. Whoever controlled counter.websiteout.net could have replaced the advertising with a fake appointment form, a payment page or a malicious redirect, and it would have appeared on the AIIMS website. On a site that patients use to find appointments and health information, misleading content carries higher stakes than on an ordinary website. The original report raised this concern, and it remains the central lesson.

Supply-chain exposure

• Inherited trust: a script tag gives the provider the same authority in the browser as the site owner's code.
• Mutable content: the code at a URL can change at any time, so approving a snippet does not approve future versions.
• Conditional serving: as this case shows, the provider can return different code to different requests.
• Availability and performance: the script used document.write, which browsers and Lighthouse discourage because it blocks page parsing and is unreliable.
• Hidden scope creep: a component added for one purpose (counting visits) can gain unrelated behaviour (advertising) without the site owner being told.

Corrections to the original report

• The original article states that ads.txt was made mandatory in 2021. Google's current AdSense documentation says use of ads.txt is not mandatory but highly recommended. The absence of an ads.txt file on aiims.edu is therefore not significant in itself.
• The article describes the ads as health-related. The one documented example promoted an online teaching platform. AdSense selects ads dynamically, so health-related ads may have appeared but were not documented.
• The article suggests that owning several domains may indicate concealment. Owning both a .net and a .ca domain is common business practice, and we do not draw any inference from it.
• The headline describes an adware infection and a vulnerability. The evidence supports the narrower finding of ad injection through an included third-party script.

No single control would necessarily have prevented this incident, and blocking all external JavaScript is neither practical nor necessary for most organisations. The controls below reduce the risk and make problems easier to detect. Each has limitations.

Applicable controls

According to the original report, the investigator identified the issue on 25 December 2022 and wrote to the Director of AIIMS. The letter explained the risks, including the possibility of malicious code being inserted, identified the third-party source and proposed a fix, with an offer of help to the AIIMS IT Cell.

The report gives no date for the letter and does not publish it or any reply. It does not describe the channel used beyond a letter to the Director, and it does not record an acknowledgement from AIIMS. We have not been able to locate a public statement from AIIMS about the issue. This case study therefore does not describe the institution's response beyond what the original report says.

Based on the evidence, the investigator observed publicly visible behaviour, examined publicly served files, reported the problem to the institution and published the details after the reported removal. There is no indication of access to AIIMS systems, exploitation or testing beyond viewing public pages. This was not a formal penetration test or commissioned security assessment.

The original report states that the AIIMS IT Cell acted quickly to remove the problem after it was reported. The web archive is consistent with that account. The last capture of aiims.edu/en.html that we found containing the counter dates from 12 January 2023, and every capture from 27 January 2023 onward omits it. In the later captures the footer shows copyright and policy links without a visitor counter. The counter appears to have been removed rather than replaced.

Not independently verified. The exact removal date, the method used, whether other AIIMS pages or properties used the same counter, and whether any other changes were made could not be verified. The archive shows only that the embed disappeared from the captured page within that window. The link between the report and the removal rests on the original article. We have not examined the current AIIMS website.

• Treat every external script as code you run. Including a script gives its provider the same control of the page as the site owner.
• Maintain an inventory. Each third-party script should have a named owner, a documented purpose and a review date. Remove what no longer has a clear purpose.
• Prefer first-party or server-side options for low-value widgets. A visitor count did not justify running an unvetted external script on a national institution's website.
• Monitor continuously. As this case shows, third-party responses can vary, so repeated sampling and change detection are more reliable than one-off checks.
• Use browser controls deliberately. CSP and SRI are useful where they fit, and their limits should be understood rather than assumed away.
• Make reporting easy. A clear security contact and a defined response process allow outside observers to report issues to the right team quickly.
• Describe incidents precisely. Accurate terms such as ad injection, compromise and malware help organisations respond in proportion and keep public reporting credible.

A visitor counter, one of the least significant features on a website, was able to place advertising at the top of the official website of a national medical institution. The evidence does not show a hacked server or malware on visitors' devices. It shows a common and avoidable dependency risk: an external script trusted with full control of the page used that control for purposes the site owner had not intended.

The investigation's contribution was to notice the behaviour, trace it to its source, report it to the institution and document it publicly. Archived evidence supports these core findings and is consistent with the reported removal. The episode is a useful reminder for any organisation with a public website to know which external code runs on its pages and to review that code regularly.