Hivint’s 2016–17 Tech Year in Review

Over the course of the 2016–17 financial year, Hivint completed 117 technical security assessments ranging from source code reviews through to whole of organisation penetration tests for our clients.

One of our driving values is collaboration, so in this spirit, we wish to share statistics and observations about our year.

We hope that by sharing this information, we’ll provide an insight into the security assurance activities delivered by an Australian cyber-security consultancy. We also hope that over time, we’ll be able to identify and present trends in the evolving nature of assurance activities — supported by clear facts and figures as opposed to general observations.


Our security assessments were delivered to Australian and international clients across a wide-range of industries, with the following chart providing the breakdown across industries.

It’s clear that our main clients for technical security assurance activities are positioned within the Finance, Government and Technology sectors, with approximately twice as many engagements performed in each of these sectors compared to the remainder. We believe that this can be attributed to:

  • The Finance industry being one of the more ‘security mature’ industries, and one that demands a high level of security assurance due to being a common attack target because of the potential of direct financial gain possible
  • The Technology industry maintaining a greater overall understanding of technical security risks and (similar to the Finance industry) demanding a high level of security assurance
  • The Government through its sheer size, and the need to obtain general periodic security assurance

The engagements completed varied greatly in the work effort, target and type of assessment performed. The 117 assessments undertaken ranged from short, single-day vulnerability assessments (intended to provide a limited, final quality assurance on a new system) to multi-month organisation wide penetration testing and vulnerability assessment activities. Engagements included configuration reviews, testing of hardware / IoT devices, mobile and web applications, wireless and network infrastructure, source code reviews and more, with web application testing being the most common assessment type (being the primary focus of 50 of the 117 assessments completed).


Through the 117 assessments undertaken, a total of 720 findings were identified. Findings which were deemed to not present a security risk (i.e. informational findings) are not included in this total.

To assess the risk of our security findings, Hivint employs an ISO 31000 aligned risk assessment framework, and employed common likelihood, impact and overall risk criteria. The table below provides a breakdown of the number and severity of findings.

The below chart provides the breakdown of the number of findings (from the Extreme down to Very Low risk severity) for each of the different industries.

Based on these ‘raw’ numbers, it’s clear that the majority of findings are presented as Low risks, with the number of findings tapering off as the risk severity increases. It is acknowledged however that these ‘raw’ numbers may be skewed due to the number and type of engagements performed for that industry — such that if the technology sector underwent the most engagements, then it seems reasonable that it would have the highest number of findings. To reduce this potential skew, the following chart has been provided which includes an average of the number of findings (for each risk rating) across the number of engagements completed for all clients in that industry sector.

With this normalised data, all industry sectors (except one) followed a fairly predictable pattern of having higher numbers of lower-risk issues, and lower numbers of high-risk issues. More mature industry sectors (such as Financial Services and Technology) showed a much more rapid drop-off as the risk of the issues increased. I.e. for these sectors, High risk issues as a proportion of all issues presented at a much lower rate, with the ratio of Low:High issues in Finance, Technology, Legal and some others being roughly 10–20:1. This is contrasted with Sports which is closer to 2:1.

We interpret this as a reflection of the focus over recent years in closing off the higher risk issues in industries such as Finance and Technology and the higher frequency with which tests have been completed against these systems.

A clear outlier in the total data set is the Retail sector which presented a higher average number of High risks than Low risks. Whilst on general we believe that the Retail sector doesn’t have the security maturity as sectors such as Finance and Technology, we expect that this level of High risk findings is an anomaly and we will be interested to review next year’s data to identify whether a similar ration of Low:High findings is present.

Monthly Breakdown

Across the year, there is a clear set of peaks by way of the number of security assessment engagements, and subsequently number of findings identified each month. The below chart presents the number of engagements and findings per month across the 2016–17 period.

The data in the above chart aligns with our experiences in working in this industry- something that we’ve seen in place for more than 10 years. The peak periods are the leadup to the end of the financial year and the calendar year, which we attribute primarily to:

  • The need to complete projects prior the end of a forecast cycle (which in Australia is largely prior to the Christmas holiday period — “I need the project in by Christmas”), and
  • The need to expend budget prior to the end of a financial cycle (which in Australia is primarily end of June).

We will be interested to see if the number of engagements across approximately November 2017 through to March / April 2018 increases as a result of entities seeking increased security assurance prior to mandatory data breach notification[i] requirements coming into effect in February 2018 (applicable to entities subject to the Privacy Act 1988).

Common Weaknesses

To categorise our findings, we follow the Web Application Security Consortium (WASC) Threat Classifications[ii] where possible. This allows us to remain consistent between engagements, and provides for a transparent view of categorisation.

Out of 720 findings across WASC categories, the top 10 WASC categories comprised 88% all findings. The below chart visualises the top 10 weakness categories that we found across the year:

The most common type of risk found was Application Misconfiguration, which is a fairly wide issue category — usually encountered when an application is not configured with security in mind — and includes issues such as a lack of security headers, or having default files disclose configuration details and application version information. The second most common was Insufficient Authentication, which can be seen when issues such as default credentials are in use, or if the application suffers from username enumeration.

Interestingly, the majority findings relate to the insecure configuration of the target system (application, operating system, network device etc.), or failing to keep the system patched to address known security issues. In a large number of our assessments, the targets are off the shelf systems that do not include any custom development by the implementing organisation, only configuration. Whilst it is recognised that some of these security findings are outside of the control of the implementing organisation (vulnerabilities in the software itself), in the majority of instances if the implementing organisation was to:

  1. Follow vendor implementation guidance for secure configuration of the system (as well as any underlying infrastructure), and

2. Keep the system patched,

Then many of these findings would not exist.


We are clearly not to the point where the need for security assurance activities through hands-on testing and analysis of systems is unnecessary due to security being sufficiently ‘baked in’ to the overall solution.

Anecdotally, we do see that organisations which invest in security earlier in the lifecycle (e.g. defining solution security requirements, performing security threat modelling, undertaking security design reviews and code assessments) result in fewer and less severe findings when implementation testing (such as a vulnerability assessment) is performed against the solution. Those that first introduce security into the project lifecycle through a vulnerability assessment a week before go-live are typically the ones with the greatest number (and higher severity) of findings.

Additionally, as the industry progresses to the use of more and more commoditised services (e.g. Software as a Service) and the number of bespoke applications reduces as a percentage of all deployments, we expect that the number of security ‘misconfigurations’ will increase as a percentage of overall findings due to a reduction in unique security vulnerabilities. We also hope that such a migration will also reduce the number of overall findings through our engagements, as an increasing number of ‘secure by default’ settings become ingrained into offerings.

Finally, we plan to keep an eye on developments across industry and relevant governing legislation such as the mandatory breach reporting in Australia, and impacts on Australian entities stemming from the EU’s General Data Protection Regulation. We expect that these macro-level changes will filter through the number and types of security activities (including security assessments) that are executed, and it will be interesting to see if next year’s data-set indicates any impact from these types of initiatives.

We hope that the data presented here has provided you with some useful insight into Hivint’s 2016–17 technical assessment activities. If you would like to see more material that we’ve shared from our engagements — such as security test cases, cheat sheets, common security findings and more — sign up for a free subscription to our collaboration portal at

Contributors: Aaron Doggett, Sam Reid, Cameron Stokes, and Jordan Sinclair

[i] Introduced through the Privacy Amendment (Notifiable Data Breaches) Act 2017 and defined as the Notifiable Data Breaches scheme. Additional details here:


Voicemail and VOIP

Commonly overlooked security risks


Every company has a phone system of some type, and just like with smartphones, these systems often offer so much more than just basic PABX functionality — technology such as VoIP, video conferencing, Unified Communications platforms, cloud based PABXs are all becoming par for the course. Most, if not all of these systems, also include integrated voicemail functionality.

This article considers some of the avenues through which attackers may look to compromise the security of a company’s phone systems.


There are many reasons attackers may be interested in a company’s phone system, including:

  • Using it to make fraudulent calls;
  • Aiding in social engineering attacks;
  • Eavesdropping on sensitive calls;
  • Harvesting sensitive information from voicemails;
  • Compiling internal directories of company staff; and
  • Attempting to obtain call detail records for market intelligence and industrial espionage.

Complicating matters is that, unlike dedicated VoIP systems and Video Conferencing systems which are often audited and maintained by the IT Security teams, traditional PaBX, IVR and Voicemail systems are often overlooked or fall outside the management purview of the IT and Security teams.

Voicemail is still relied upon for everyday use by many organisations, and sensitive information is commonly left in voicemail messages. A motivated attacker targeting a company is highly likely to be able to gain valuable information by listening to the voicemail of system administrators or executives over a period of time.

With cheap VoIP services being readily available it is also simple for attackers to automate and scale up their attacks to make multiple simultaneous calls and complete them faster. There are many ways to automate phone attacks, and it is easy for an attacker to write a script or use existing software to automate a range of attacks, including those outlined below.

Types of Voicemail and VOIP Attacks

Brute force attacks

Having a four-digit PIN as the de facto standard for voicemail authentication means an attacker will have a reasonable chance at successfully guessing the PIN through manual avenues such as by just using the phone keypad. Even with longer PINs, common patterns and repeating numbers are so commonly used by staff that an attacker is likely to work out the PIN using a PIN list instead of having to manually enter in every possible combination of digits.

In combination with most voice mail and phone systems not supporting account lockouts, nor having other security controls such as logging and alerting, which are commonly applied to other IT systems, undertaking a successful PIN brute force attack to gain access to a staff member’s voicemail box is unlikely to prove difficult to the determined attacker. Additionally, there are also methods to bypass lockout timers in those instances where they are in place. One technique that is almost always successful on large voicemail systems is attempting two or three common PINs against every extension or user account. This would prevent triggering any account lockouts, if implemented.

Once an attack run is complete the attacker may well have access to several voicemail accounts.

Directory reconnaissance

The same automation that can be applied to PIN brute force attacks can also be used for other attacks against phone systems. One example is the creation of internal directories. An attacker can use the “find extension” feature of modern PABXs and voicemail systems to make a list of names, extensions and sometimes job titles within a company. They can also do this by calling and making a note of every greeting for every extension if the PABX doesn’t have a names directory feature.

Call-forwarding attacks

Another use attackers have for voicemail is the call forwarding feature which can be used for free phone calls or to aid in social engineering attacks.

Getting free phone calls is the simplest example. An attacker who has compromised a voicemail box sets up call forward to a mobile phone, overseas or other toll number they want to call, then calls back the local DDI number or the company’s main toll-free number and enters the extension number and waits for the call-forward to connect them to their pre-programmed toll number.

This attack can be reversed as well — an attacker can also use a compromised voicemail box to receive incoming calls using the call forwarding feature to forward calls to a VOIP or pre-paid phone controlled by the attacker.

They then will have control of an extension on that company’s phone system which they can give to external parties to call back on to appear like they are inside the company’s office, which can be an invaluable means to facilitate the commission of a further social engineering attack.

Leveraging Caller ID

Most phone systems, when call-forwarding is used, display the caller-ID of the voicemail extension rather than the number of the originating party.

An attacker may be able to leverage the call-forward feature to masquerade as a known external party, such as appearing to be a known vendor or to be calling from inside the target company’s building. This can gain greater traction for social engineering purposes.

On a penetration testing engagement some years ago, my colleagues and I took over a manager’s extension at corporate headquarters and set up a call forward to the security desk at one of their rural sites. We called ahead to the security desk to add our names to the visitor register. The security desk asked very few questions because their phone displayed the call as originating from the manager’s phone at the organisation’s headquarters.

When we arrived, the security desk was expecting us and allowed us to enter without any restrictions.


The attacks scenarios above relate to simple voicemail systems, which most people overlook, considering them to a straightforward way to store and retrieve messages. However, when you include customer facing IVRs, VoIP systems, PABX systems, Teleconferencing and Video Conferencing systems, Unified Communications systems, call-queue management systems and the endless other applications of modern phone systems, then the possible vulnerabilities that can be exploited by attackers are almost endless.

Large companies often own a block of numbers, generally in lots of ten thousand. It is a good idea to periodically audit these number blocks to classify all lines, then performing an audit of possible attack vectors of all the phone systems connected to them.

Practicing the same security hygiene for voicemail that you do for other systems is critical, for example:

  • Disabling default accounts;
  • Auditing voicemail boxes for common PIN’ or disallowing common or simple PINs;
  • Setting a minimum PIN length of six digits;
  • Setting unique temporary PINs when provisioning new voicemail boxes;
  • Setting up lockout timers that don’t lose their state over multiple calls;
  • Disabling call forwarding features;
  • Restricting allowed forwarding numbers to local mobiles and landlines only;
  • Deactivating unused voicemail boxes; and
  • Applying logging and alerting if possible.

With some phone systems this is often easier said than done. We hope this article gets you thinking about how your company uses and manages phone systems and how they might be abused by attackers if appropriate vigilance is not exercised.

Article by John McColl, Principal, Hivint