When we began our research into the cybersecurity postures of political parties, we started with what we had: the scorecards generated by the SecurityScorecard. The great thing about using a security scorecard is that it can quickly illuminate hosts that are off to the side- the forgotten infrastructure that has fallen into a neglected state. Often, a primary domain, like www.politicalparty.com will be well taken care of, after all, it’s the starting point for anyone looking for information.
After establishing that there’s no obvious issues on the primary domain, such as unpatched, known, vulnerabilities, a very easy next step is to examine certificate issues throughout the organization. Certificates fall into three main categories: expired, self-signed, and revoked, with only the first two being seen with any frequency. When looking at expired certificates it’s helpful to ask questions like: Is this host still active and used?
Are users accepting the expired certificate because it’s required for them to complete their work? Self-signed certificates are often an indicator of a network appliance, or a piece of software that is automatically configured during setup. Many deployments are done in a way to get to usability in the shortest time possible. As a byproduct of this behavior, these appliances and applications quickly become critical to workflows, which means that taking them offline, for whatever reason, when it appears to be working just fine, is not seen as an option. This can lead to easy identification of products that may be using default, known, passwords, or easy-to-match versions that are known to be vulnerable.
Both of the above certificate issues speak to the security hygiene of an organization.
Another quick win in terms of determining the utility or purpose of a host, beyond a rather obvious mail.politicalparty.com address, would be something within the realm of district-mapping-state.politicalparty.com. While naming a host something that is meaningful is helpful for the users of the service, it also helps would-be attackers determine what information may be held therein.
Since the information gathered by SecurityScorecard is done so in a very low impact, and non-invasive manner, it is possible to go beyond the information found in a scorecard, while still using the information to further guide your next steps.
Remember the mention of hygiene when discussing certificates? Well, when deciding which hosts warrant further investigation, the hosts with the worst hygiene are a great starting point. SecurityScorecard limits the ports that it scans at scale to be a good citizen of the internet, but a motivated attacker will have no such compunction. Scans against single hosts to determine listening services, especially those on alternate, or non-standard ports, is a great way to find services that have been long since forgotten. Finding APIs, test sites, and other applications can all be excellent ingress points for a motivated attacker.