DDoS Attack Types

DDoS Attack Types

  1. Volumetric attacks, which are believed to comprise more than 50 percent of attacks launched, are focused on filling up a victim’s network bandwidth. Among the most common volumetric attacks are User Datagram Protocol (UDP) flood attacks, where an attacker sends a large number of UDP packets to random ports on a remote host. UDP floods accounted for approximately 75 percent of DDoS attacks in the last quarter of 2015, according to the Versign DDoS Trends Report. A common form of UDP flood attack relies on reflection and amplification. UDP is a connectionless protocol (that is, it doesn’t require that the two ends of a conversation establish a connection before exchanging data). An attacker can therefore forge UDP packets with fake source addresses, and use those packets to generate reply traffic. By setting the source of the UDP packets to be the IP address of the intended victim, and then sending those packets to various servers for UDP-based applications, the attacker will cause the servers to send reply traffic to the forged source IP address–the victim. This reply traffic is the “reflection” part of the attack. It’s a lot like calling every pizza place in your county, and ordering a lot of pizzas to be delivered to someone you really don’t like. The “amplification” part comes in when you understand that many UDP services generate replies that are much larger than the initial request size. For instance, the Domain Name Service (DNS) has a bandwidth amplification factor of 28 to 54 (the reply to a DNS request can be between 28 and 54 times larger than the request). The Network Time Protocol (NTP) has a bandwidth amplification factor of 556. By combining reflection (the server sends reply traffic to a spoofed source address) with amplification (the reply traffic is a lot larger than the initial request), attackers can do a lot of damage to a victim with very little effort on their part. A number of UDP-based applications and services can be used to generate amplification and reflection attacks, including DNS, NTP, Simple Service Discovery Protocol (SSDP), and Simple Network Management Protocol (SNMP).
  2. Protocol attacks (sometimes also called state-exhaustion attacks) target a weakness in how a protocol operates. A well-known protocol attack is the SYN flood, which targets the three-way handshake mechanism in TCP. When a server receives a SYN packet, this is a signal to the server that another machine wants to open a TCP connection. The server will allocate some of its resources to this half-open connection, and send a SYN ACK packet back to the initiating machine. Under normal circumstances, the initiator will then send an ACK packet to the server, the three-way handshake is complete, and the machines will then exchange data. In a SYN flood attack, an attacker sends a rapid succession of TCP SYN requests–typically from spoofed source IP addresses–to open a connection to a network server. The server sends SYN ACK packets back to the source addresses, which never reply with an ACK. The server keeps the half-open TCP connections around, using up resources, until the server is no longer able to accept any new connections.
  3. Application attacks target weaknesses in how an application works. One well-known application attack is Slowloris, which targets web servers. In a Slowloris attack, the attacker sends HTTP requests to a web server without ever completing the requests. Periodically (and slowly–hence the name), the attacker will send additional headers, thus keeping the request “alive” but not finished. Similar to a SYN flood, this forces the web server to maintain open connections for these partially completed HTTP requests, eventually preventing it from accepting any new connections.

CISO Strategy

CISO Strategy


What the CISO Should Do to Help the Board Make Informed Decisions Around Security and Risk

  1. Develop and communicate a security mission statement rooted in business enablement
  2. Determine your risk appetite and document your risk tolerance in layman’s terms
  3. Choose a security framework and map initiatives to that framework
  4. Establish unbreakable rules around security responsibility and information sharing
  5. Keep the board updated on security trends and be prepared to discuss specifics, such as how the organization is responding to a specific threat drawing headlines

What the Board Should Do to Support a Culture of Security Awareness and Accountability

  1. Approach and understand cybersecurity as an enterprise-wide risk issue
  2. Learn the legal implications of cyber risks
  3. Access cybersecurity expertise by giving cyber risk discussions adequate time on the board meeting agenda
  4. Set the expectation that management will establish an enterprise-wide risk management framework with adequate staffing and budget
  5. Discuss cyber risks from the perspective of identifying which risks to avoid, mitigate, accept, or transfer through insurance, as well as specific plans associated with each

Personally identifiable information (PII) Examples

Personally identifiable information (PII) Examples

PII is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used for de-anonymizing anonymous data can be considered PII.



  • John Smith + Trustwave = GDPR
  • John Smith + Phone Number = GDPR
  • jsmith@trustwave.com = GDPR
  • PII; car number plate, national insurance , passport number, NI Number all = GDPR
  • 407 Southway Drive Plymouth + John Smith = GDPR (fictitious address)
  • Post Code + car reg = GDPR
  • Medical record = GDPR
  • Cookies = GDPR
  • IPaddress = GDPR
  •  Princess Diana  does not apply to GDPR as she has deceased.
  •  Prince William = GDPR
  •  Essentially any information that can identify a living person can be in scope of GDPR even indirectly can come into scope of GDPR:
  •  For example if I was to write a blog then just by the content of the blog if I can be identified , i.e. by style of writing or subject it could indirectly come into GDPR

Incident Response

Incident Identification

Step 1: Prepare your documentation

You will need to document all your activities, from meeting minutes and decisions down to commands typed into your systems by your incident response team.


For each step, you will need to record, at minimum:

  • Identifying information (location, serial no, model no, hostname, MAC address, IP Address)
  • Name, title, and phone number of each person who collected or handled evidence during the investigation
  • Time and date (including time zone) of each occurrence of evidence handling
  • Locations where the evidence was stored

Step 2: Assemble your Team

Get your incident response team together! Where possible use phone communication – your email and chat systems may be compromised and you might tip off an attacker that you are aware of them.

You’ll need a broad set of people:

  • Security personnel, including incident responders
  • System and network administrators
  • Business stakeholders, such as PR

Remember! Apply a need-to-know policy for now – no need to blow it out of proportion just yet.

Hint: If you have Cyber Insurance, notify them of a potential claim.

Step 3: Determine Scope

Working with your team, determine as best you can what devices have been compromised.

Assume the worst – that more of your environment is compromised. Yes, it will increase the scope of the response, but will reduce the chance of an incident recurring.

‘Indicators of compromise’ are unexpected or suspicious behaviour which may mean an incident has occurred. This may include behaviours such as:

  • Strange or unexpected system activity
  • Alerts from a Network IDS or Antivirus system
  • Unscheduled system crashes or server reboots
  • Unexplained configuration changes, unusual files, unknown processes, unexpected web-site changes, etc.
  • Influx of phishing e-mails, spoofed e-mails, etc.
  • Unusual activity in log files, or gaps in or missing logs
  • E-mail system showing a large number of bounced/invalid emails
  • Large volumes of network traffic to unknown countries and networks


Step 1: Contain to Affected Systems.

A hacker will try to traverse to other systems, so isolate affected systems as soon as possible. The goal here is to prevent the problem from getting worse.

There are some key actions – these may affect incident response, forensic, and legal activities, so make sure you do it right:

  • Do unplug the network cable of affected systems
  • Do suspend affected VMs (a copy of the RAM is taken, which is important for forensic analysis)
  • Do disable wireless connections (in order of preference: at the router, hibernating the laptop, then disconnecting via the computer operating system)
  • Do declare an incident, if it appears to be one
  • Don’t run an anti-virus scan (this changes timestamps)
  • Don’t shut down operating systems

Step 2: Backup affected systems

You want to keep copies of the affected system for forensic purposes.

The best approach is to remove the affected system from the environment, and provide a new system for the user, or build a new server from a clean SOE.

Of course, sometimes this isn’t possible, in which case you should:

  • Obtain a brand new disk drive and create a complete bit-for-bit backup; and
  • Get another copy on write-once media (CD-R or DVD-R) in the event that you need pursue legal recourse.

Hint: Use the ‘dcfldd’ tool, which is available for Unix and Windows.

3rd party forensic investigators will have disk cloning hardware to perform this task if you don’t have the relevant expertise.

Eradicate the Problem

Step 1: Remove the malicious code

Eradication means removing the problem from affected systems determined through your scoping efforts.

The actual technical actions for eradication may vary considerably.


For attacks on vulnerable systems, cleaning the system and patching the system may be sufficient.

Malware outbreaks

It can be very difficult and time-consuming to verify that systems are in fact secure, and malware has been completely removed. Rootkits in particular need specialist skills to detect.

We recommend rebuilding systems affected by malware, by either:

  • Reinstall the operating system from original media or image, and restore data from the last known good backup onto new media;
  • Wipe the existing media, reinstall the operating system from original media, and restore data from the last known good backup;

See the eradication tools in the Links below.

Step 2: Apply compensating controls

If you have indeed been breached, it will be best to apply further controls to ensure you are better able to prevent and detect malicious activity next time.

These controls may include:

  • Additional logging and monitoring of systems, applications, and databases
  • Increased monitoring of infrastructure logs, such as SIEM, firewalls, and IDS/IPS
  • Restriction of logical access to databases
  • Additional network segmentation
  • Restrict access to databases


Step 1: Recover your systems

Once you’ve eradicated the problem, you can recover the affected systems and return them to production.

Remember to check the integrity of your backups before restoring from them. Malware may have been backed up with your system and data files.

There are key actions when you recover your systems:

  • Do patch all affected systems
  • Do check and remediate the original attack vector
  • Don’t re-introduce the vulnerability from your backups

Step 2: Monitor your environment

You need to conduct logging and monitoring of systems and network traffic to verify that the system or environment has been remediated.

  • Setup a sniffer on a switches span port to capture all network traffic
  • Log all traffic and send to your logging and monitoring solution
  • Check for further activity on the network

If you’re satisfied that the attack has been completely eradicated, then you can formally terminate the incident and conduct post-incident activities.

Have a look at our Incident Response Guide (available to subscribers) for supporting information on conducting post-incident activities, and preparing for the next security incident.

Incident Response Flow Chart

 What to capture

  • Network Diagram
  • Internal LAN IP Address(s)
  • External WAN IP Address(s)
  • Log Files
  • Firewall
  • IDS / IPS
  • Web / Proxy Server
  • Other Application Logs as Needed
  • PowerShell ▪ SQL
  • RDP
  • DNS
  • Active Directory
  • Disk Images for Affected Systems
  • Forensic Image of Disk
  • Volatile Memory Capture o Event Logs
  • Specific Application Logs
  • Detailed Timeline Prior to Engagement


Eradication Tools

Microsoft Malicious Software Removal Tool
Avira Rescue System
McAfee Stinger Malware Removal Tool

Forensic Tools

  • Google Rapid Response – https://github.com/google/grr
  • GRR, Rekall, plaso (log2timeline), The Sleuth Kit (TSK), libyal, or alternatives like Guidance Encase, AccessData FTK, X-Ways Forensics, Cellebrite, Volatility, Mandiant MIR, etc.

Incident Reporting

Australian Cybercrime Online Reporting Network (ACORN)
CERT Australia

Data Breach Infographics and Cyber Security Research Reports

Data Breach Infographics

Cyber Security Research Reports