To slightly modify something that Edwin Starr sang in the 1970 hit “War“
What is it good for?
In most environments, the WINS service is no longer necessary as the Netbios protocol is no longer needed for name lookups (now handled by DNS).
Netbios can (and should) be disabled on all endpoints (servers and workstations). Windows OS Hub has a great article on how to do that. But that still might leave the WINS service running on servers in the environment.
To detect the state of the WINS service on all Domain Controllers, I created the PowerShell script below. It gets a list of all DCs, then determines if the WINS service is installed or not, then gets the state of the WINS service.
$Servers = @(Get-ADDomainController -filter *).name
Foreach ($Server in $Servers)
$WINSService = Get-Service -ComputerName $Server -Name WINS -ErrorAction SilentlyContinue
Write-Host "$Server,not installed,"
This script needs to be run as a user with the ability to query services on Domain Controllers.
It will write its output is CSV format similar to what is below:
This should help identify Domain Controllers that are still running WINs or that have the service installed, but stopped.
Tenable.SC has a basic ticketing system built into their product. But, by default, there’s no way to notify someone that a ticket has been assigned to them. To notify someone that a ticket has been assigned to them, an alert needs to be generated that is based on a query.
The first step is to configure a query. Within Tenable.SC, navigate to Analysis → Queries and Add a query. In the Query Builder section, select “Ticket” for Type and “Ticket List” for Tool.
Nexpose, like other vulnerability management platforms, has the ability to create exceptions for the vulnerabilities it finds. You might need to issue exceptions because the vulnerability is a false positive, a compensating control is in place, or the risk is acceptable to the business.
Unfortunately, you sometimes have to create exceptions for hundreds, if not thousands, of vulnerabilities within Nexpose. It’s far too time consuming to create those manually.
The good news is that Nexpose has a well documented API. I’ve used this API to create a Powershell module that can help automate the submission of vulnerability exceptions.
Have you ever been looking through Active Directory and notice something strange in one of the fields? Maybe the Organization or Description field has a weird string of letters, numbers, and characters. You think, “Huh, that kind of looks like a password.”
Ding! Ding! Ding!
Yes, it happens. Either through lack of understanding or just laziness, sometimes passwords get put into the plain text fields in AD. This is dangerous because those fields are readable by everyone on the domain.
So how do you know if any of these fields are being used to store passwords? I managed to cobble together a PowerShell script that can help. (more…)
Some time ago, I posted a PowerShell script to detect changes in external NS records for domains. I’ve made some modifications to the script to reduce false positives. Additionally, the script now emails the “before” and “after” results of the NSLookup command for easy comparison.
Updated script is below: (more…)
UPDATE: A newer version of this script is here.
Last week, Johannes Ullrich shared a Bash script that would check for changes in NS records. This was in a blog post about the google.com.my DNS hijack. I wanted to create a version of the this script that would be usable on Windows machines. So I created the PowerShell script below that does pretty much the same thing as the Bash script. The script runs nslookup.exe instead of DIG and queries the DNS server for all NS records for a domain. This is saved in file named domain.new and compared with a previous query of the NS records stored in domain.old. If there are any differences, an email is sent and an entry is made in the Application Event Log. (more…)