I love working with schools. I love seeing young students exploring technology that I could only dream about when I was younger. (In some ways, I guess that is why I live by a major university here in North Carolina.) So when I am scheduled to meet with a school, I know that it is going to be an exciting call. Yesterday was no exception.
I was working with a good-sized school system and the evaluator really needed a way to get better visibility into their network traffic. He also wanted to explore how they could use NetFlow as an added security layer.
DDoS Attacks: Modern Day Fire Alarm Prank
One thing that he mentioned during our talk was the use of DDoS attacks as a “modern day fire alarm prank.” Back in the day, kids used to pull the fire alarm to get out of tests or just to pull a prank, but I never thought of how this might have changed in today’s world. Despite the intent being more mischievous than malicious back then, the consequences of this behavior are now more severe. Nevertheless, it hasn’t stopped. Honestly, the concept of students attacking a school wasn’t new to me, but associating that scale of an attack with the term “fire alarm prank” made it click. I decided to learn more.
After some Googling, I found an interesting story; six UK teenagers were arrested for using Lizard Squad’s Lizard Stresser DDoS service to attack multiple locations, one being a school. Although this was similar to my concept of students disrupting the daily routine of a school system, it wasn’t the example I was looking for. It wasn’t until I found a story about two teenagers from Idaho that I felt I was on the right track.
Back in 2015, a 17-year-old from Idaho found himself in a lot of trouble after orchestrating a distributed denial of service attack that forced the entire West Ada school district offline. This wasn’t a small task—the West Ada School District is the biggest in Idaho, with 52 schools and over 36,000 students. This attack effected everything from payroll and attendance to online classrooms/textbooks and standardize testing. Testing was the example that I was looking for. In this example, students who were taking the Idaho Standard Achievement test were required to go through the process multiple times because the system kept losing their work and results. Maybe this attack example isn’t Ferris Bueller’s Day Off– type shenanigans, but the attack model is what I was looking for. So what went down?
Modus operandi
I had to put on my NetFlow Detective hat to learn more about what these kids did. Most of the articles didn’t elude to how they determined the students’ IP address, but they do suggest that he used a 3rd-party service to conduct the attack. This method of attack was similar to the UK students who used a 3rd-party Stresser. But would this type of technology have been available to our friends in Idaho?
I didn’t have to go too far to find an answer. Matter of fact, my buddy Jake here at work makes it quite clear in his post about detecting DDOS Booters with NetFlow that all you have to do is Google for booter websites or network stress testing to find plenty of services and tools. The next question is how might this type of attack be reflected on a network?
There are multiple attack vectors to consider. You might see a combination of a UDP Flood where the attacker sends UDP packets—typically large ones—to a single destination or to random ports. You might, as I mentioned above, see Reflection Attacks or Reflective denial-of-service attacks, which makes use of a potentially legitimate third-party component to send the attack traffic to a victim, ultimately hiding the attackers’ own identity. Others methods might be SYN flood attacks, attacks from mobile or IoT devices, and many more. Remember that it could also be a combination of methods.
In these types of attack you need to monitor for multiple patterns to detect what is going on. Basically, as a security professional, you need to make sure your toolset is flexible enough to monitor for multiple signatures AND attack patterns. It also needs to be smart enough to see through the static and determine IPs of concern.
Although in the case of the Idaho school the attack appeared to be initiated externally, that doesn’t mean internal infected IPs weren’t involved. At some point they were able to stop the attack (or it just stopped on its own), but there is still a question of whether they just fixed a symptom and whether there is a larger issue. That is why I suggest collecting historical conversation data. Having this information is vital during the investigation phase. The good news is that you can use technology like NetFlow to easily keep a record of every conversation that comes across your network. When the smoke settles, you can easily dig into the data and find other infected machines.
Suggested protection to consider
- A multi-layered solution that provides complete visibility into all of your network traffic, monitors for threat patterns or IOC’s in that data, and has the ability to be integrated into other on-premise detection and mitigation tools. Things will happen. This approach helps facilitate quick detection, immediate response, and internet pipe saturation.
- Solution must help distinguish between legitimate and attack traffic, having the ability to integrate with other mitigation solutions to block it while also protecting the SLA.
- Create a cyber-security emergency response plan
Conclusion
Keeping a school’s network safe and running is not only mission critical, but in many cases required by law. If you would like to discuss how Scrutinizer can be used to monitor and detect abnormal behavior on your network, contact our team or download a free trial of Scrutinizer.