Advertisement banners (e.g., banner ads) you see on many websites today are stored and delivered to website visitors by dedicated ad servers. These ads can sometime contain malware (known as malvertising) where malicious code is injected into legitimate online advertising networks.
As a way to mitigate against potential malware infection from ads, known addresses of ad servers can be used to block them from delivering potentially malicious content to your company's computers as your staff visits various websites.
This is accomplished by associating ad server names to the loopback address of 127.0.0.1 in the HOSTS file that resides on each end user's workstation. In Windows, the default location for this file is in "C:\Windows\System32\Drivers\etc" and on a Macintosh, it is located in "/private/etc/hosts". The HOSTS file will contain entries similar to the example below:
127.0.0.1 adbanner.ro
127.0.0.1 adbard.net
127.0.0.1 adblade.com
127.0.0.1 adblockanalytics.com
127.0.0.1 adboost.de.vu
127.0.0.1 adboost.net
127.0.0.1 adbooth.net
127.0.0.1 adbot.com
127.0.0.1 adbrite.com
127.0.0.1 adbroker.de
It is a list containing thousands (at least for my project implementation) of ad servers - all are prevented from going out to the Internet to fetch ad content. This is accomplished with the loopback address 127.0.0.1. When resolving hostnames, a computer by default will initially search its HOSTS file for the IP address. If it finds a matching hostname, it will use the IP address that's paired to it. By pairing these ad server with a loopback address, a computer will query itself for the ad content and end up coming empty handed.
For example, if a web page you are visiting contains a script that calls an external ad server, such as the example shown below, as long as acmeadserver.com is listed in your HOSTS file with an IP of 127.0.0.1, no content will be delivered by acmeadserver.com.
<script src="http://www.acmeadserver.com/ads.js"></script>
The other content of your web page will still load, and the spots where the ad would have been displayed will typically collapse (at least for responsive websites) so you don't end up seeing voids.
This setup is essentially an alternative implementation of an ad blocker. The advantage of this, versus say a browser extension, is that you are able to centrally manage this from your Windows Server and your users, for the most part, will not be able to "disable" it. Additionally, if you have users that take their company-issued notebook home or on the road, the HOSTS file will still be there protecting your endpoint from ad/malicious servers.
There are third-party websites, such as http://pgl.yoyo.org/adservers/, that maintain a list of current ad servers and updates it regularly. It should be noted that these lists will typically include legitimate servers, not just servers identified as being malicious. The few providers that I've encountered make their list available to the public at no charge and can be downloaded in a format compatible with the HOSTS file syntax. This allows the downloaded list to be copied-and-pasted into our HOSTS file without any edits or manipulation. The delivery of the HOSTS file to end user's workstations can be accomplished using the file replace action found in the GPO tree path Computer Configuration > Preferences folder> Windows Settings. Place your updated HOSTS file on a network share and GPO will push our the file every your user logs into your network.