In all scenarios the ability to clearly identify what and who is exposed to the internet is the first stage of an attack. This can be as simple as an internet-wide port scan, scraping data from well-known aggregators such as Shodan, Censys, etc., spidering websites for pages and documents that shouldn’t exist, or more advanced and granular checks.
CovertSwarm’s Offensive Operations Centre (OOC) has been built to replicate these initial stages and to give you the ability to action these in a simple manner that doesn’t require prior security or penetration testing experience.
Discovery: Technology
Our suite of in-built automations can aid your attack surface discovery, starting from a top-down approach from something as simple as your organisation’s primary domain.
Execute subdomain enumeration of a domain
Running the Subdomain enumeration automation initiates a background task for the OOC to go out and passively identify all of the subdomains through a number of ways:
- Certificate transparency logs – Where a certificate has been created for one or more subdomains, we capture this as a snapshot
- DNS brute forcing – Without touching your infrastructure the OOC identifies the more common, and some of the more uncommon subdomains
- Aggregated data – Using well-known services such as Shodan we supplement the captured subdomains with those of previously identified subdomains
As a result of this the OOC is then updated with the identified FQDNs from the subdomain enumeration, and any passively identified services for the respective hosts are included within the results.
With one quick action we’re able to see not only the subdomains that are present (historical or newly created), the services that were able to be enumerated, but also the software associated with these services (where applicable) and the resolved IP addresses (both IPv4 and IPv6).
Once these new technology assets have been created (or updated with the latest information) further automations can be run against these. At present, the Offensive Operations Centre offers the following:
- SPF & DMARC vulnerability identification
- Web Application enumeration
- Host service & software enumeration
Read to the end to hear about our upcoming features as we continue to grow our capabilities over the next 6-12 months.
However, during the subdomain enumeration automation each of the identified subdomains/hosts are checked for email capabilities through valid MX records within their DNS configuration, and if present the SPF & DMARC checks are performed automatically. Additionally, each of the IP addresses enumerated through the subdomain enumeration and the SPF included IP addresses are subjected to passive enumeration; thereby providing instant access to all of the possible information that could be gathered without needing to lift another finger.
You can of course initiate these manually at any point, should the need arise.
What is the purpose of the SPF & DMARC checks?
I’m glad you asked.
One of the main protections against email spoofing attacks, which are far too often successfully used in phishing attacks, are the SPF, DMARC (and DKIM) controls that are configured via DNS records. Just to set the scene so that we’re all on the same page with the initialisms:
- SPF – Sender Policy Framework: This is used to define permitted senders for a domain (and/or subdomains) as part of an authentication workflow
- DMARC – Domain Message Authentication, Reporting & Conformance: DMARC is a complicated workflow, but essentially builds upon the use of SPF and DKIM technologies to a) define how SPF and DKIM failures should be handled by recipients, and b) reports to the administrator(s) of the specified domain relevant data about failures and usage
- DKIM – DomainKeys Identified Mail: The use of DKIM is for message signing, which enforces the ability for recipients to validate the original of an email from a sending domain
Unfortunately, validating a DKIM configuration without a sample email is not possible, at least in an automated manner. Our development team at CovertSwarm are hard at work bringing a semi-automated solution in to the OOC to ensure that we are offering as much coverage in this area as possible.
However, with both SPF and DMARC these policy configurations can be easily audited from a best-practice standpoint. Some of the areas we check for include:
- Insecure DMARC policy (p) settings: this includes policies that are set to ‘none’, which effectively nullifies any configuration that has taken place elsewhere
- An insecure configuration for the DMARC percentage (pct) flag, which defines how many of the received emails should be subjected to the relevant email policy checks.
- SPF records that could allow spoofed emails to be received by recipient gateways, such as the use of the ‘+all’ or ‘?all’ policy flags
- Maximum lookups being reached for SPF ‘includes’ effectively nullifying the policy
- Duplicate SPF records, which again nullify the policy being set
- Invalid SPF/DMARC configurations
As a result of performing these, and many more checks, the OOC raises vulnerabilities against the relevant assets with an appropriate severity. The goal of this automation is to highlight the more pressing issues, but to also make your organisation aware of areas that could be further improved.
One of the key concerns from a security perspective is where a parent domain enforces SPF, DKIM, and DMARC correctly, but has no configuration applied for its subdomains that are mail-enabled. In these cases it is possible to perform spoofing-attacks from/against these subdomains.
Discovery: People
A key weakness that is often exploited is the human element of an organisation. Time and time again our Hive teams have successfully breached organisations through phishing attacks, vishing attacks, and (for lack of a better word) in-person social engineering attacks. In addition to this, data leaks have become more wide-spread with public knowledge and as a result of that credential-stuffing attacks have become more wide-spread with public knowledge and as a result of that credential-stuffing attacks have become rampant.
One of the automations we’ve recently deployed allows for the discovery of publicly available email address information at the click of a button.
Initiating this automation against a domain will passively discover people within your organisation, their email addresses, departments (where applicable), and other organisation-specific details.
Once these have been identified by the OOC, an informational vulnerability is raised for each of these individuals that highlights where this information was found, how recent this is, and whether it is still present on the relevant websites.
Identifying Data Breaches
Similar to the email address discovery, the OOC provides the ability to identify email addresses that have appeared in publicly-leaked data breaches. For each domain asset registered within the OOC, you can run a data breach discovery automation that will check for historic data breaches (which are updated/validated daily).
Any individuals that are recorded within a data breach will have a vulnerability created against them to highlight which breaches they were found in, the details of the breach (and what this extends to, such as passwords being leaked, personal data being included, etc).
An example of a data breach vulnerability against an individual
Discovery: Dark Web
A new feature that was recently added to the OOC’s repertoire is that of the Dark Web enumeration.
In my career as a penetration tester there have been many occasions where clients would ask for a brief activity to discover possible discussions of their organisation on the dark web. This is a costly activity in many ways, mainly due to the time required, which translates to financial cost.
At CovertSwarm we’ve taken to automating this activity as much as possible.
By initiating this automation through the OOC the specified domain will be checked across many ‘known’ places throughout the dark web for mentions of the domain name. Any records of this will be raised within a vulnerability with the locations (URLs) and relevant information to assist you in identifying what has been discussed and whether there is any inherent risk (such as information being sold).
This automation is a stepping stone towards awareness, but isn’t perfect. Due to the nature of the dark web being dynamic and ever changing, dark web discovery cannot be fully automated. However, our development team will continue to develop and improve this automation over time.
Looking to the future
As the Offensive Operations Centre continues to evolve, both from the feedback of our Hive delivery teams within the ‘Swarm’, and from continued feedback from our clients who have subscribed to our services, we aim to bring a greater suite of tools and automations into the fold.
Some of these include:
-
Automation scheduling – define the targets, automation type, and schedule the automations to run on a recurring basis
-
Active port scanning – configure a scan profile, select and/or input the targets, and initiate an active port scan that will essentially monitor your endpoints, software, and services
-
Physical asset discovery – enumerate office locations related to your organisation, and what the world is aware of them
-
Further web application enumeration – identify not only the URI paths, but the software associated with the applications themselves, common or uncommon weaknesses, and API detection
-
Organisational domain detection – identify other domains owned by your organisation
-
Lookalike / spoofed domains – become aware of possible typosquatting domains that could be used to attack your organisation in phishing attacks
If you would like to enquire about the Offensive Operations Centre please reach out to us via our contact form and our team will get back to you as soon as possible.
