I operate like a python, the venomous snake that quickly attacks its prey with practically no time reaction time. I want my victims to be in a peaceful state right before I unleash mayhem. I discovered a vulnerability that would allow me to attack individual victims for years to come without detection until it was too late. As awesome as it would be, I decided it was best to adapt my python attack.
This new exploit would enable me to instill fear into the masses if timed appropriately. Without high profile targets in my attack list, what would be the benefit of attacking a few dozen persons when I can make millions panic? What animal waits for it to be announced and immediately thereafter attacks?
I knew I needed to find an exploit that would apply to many, irrespective of device type. I used the STUXNET [1] exploit as a source of inspiration. It took advantage of a feature that was largely overlooked and taken for granted. Of course, STUXNET was more sophisticated than the average exploit, mine would never rise to its level of sophistication. Yet sometimes the simplest attack vectors are the grandest. [2] My exploit would be grand because it would attack the ubiquitous.
I knew I needed to experiment to find the optimal attack strategy. Experimentation would require trying numerous single exploits and assessing its effectiveness. Furthermore, I would characterize the throughput, payload type, and probability of success. This would allow me to devise follow on experiments where multiple exploits are daisy chained and run in parallel. After a series of experiments, I could begin laying the foundation for an uber exploit.
I downloaded the latest open source hacker tool set. [3] I chose the most promising attack vectors from the catalog. After a few days of reading the bits and pieces of documentation and rummaging through the source code I had a comprehensive understanding how each payload worked. I created a checklist of the payloads and matrix documenting where I installed the hacker tool set, the target platform, and notes for each attempt. I installed the tool set on the different machines from which I would launch the attack and was ready to start experimenting.
My first set of runs were done in an radio frequency controlled room. I wanted to eliminate any radio frequencies from entering and distorting my collected data. Furthermore, I would avoid premature discovery of my plans. I ran some initial calibration checks to ensure no signals were going in and out of the room.
I was ready to begin experiments. I did consecutive runs that took about four hours total. I would wake up, do my morning routine, eat breakfast, kick off a four-hour test, and run to work. I would return during my lunch break to eat a cold sandwich over my central computer while evaluating the success of my run. After confirming I had meaningful results, I would kick off the afternoon test, and run back to work before my supervisor would accuse me of taking too long a lunch. (Some supervisors are horrible and don't appreciate their employees. I would do what I was asked, she would be cheery and thankful to my face, and then complain to my manager that I did not show enough initiative. Though when I tried to go above and beyond in the past she would complain I was overstepping my bounds. I digress. Maybe she will be in the first round of targets when I launch the python attack.) [4] I would spend the rest of the evening after work number crunching both sets of tests. I would then set up both sets of tests to run the next day. I followed this same schedule even on the weekends. My experiments became my highest priority other than staying employed to finance them.
I eventually had a series of exploits to test in the field. I would pick locations with many targets where I could blend into the crowd. I wore nice slacks, a collared shirt and a wool sweater. The day before I would go to a fancy chain hair salon and ask for haircut to match the cover model. If anyone were to approach me I could easily respond I was waiting for a blind date who was running late. My testing would be inconspicuous.
I decided to pick a location with a consistent level of churn. I found a place where the crowd would change approximately every twenty minutes. This would allow me to run three tests. An hour would be a reasonable amount of time to wait before leaving after having been stood up by a blind date.
In the first test I would try as many single exploits in the order of most likely to succeed. I would leave five minutes to calculate the success ratio. I streamlined the process for it to all work from my phone. Launching exploits from a phone would be harder to pinpoint as the majority of persons would be using their phone too. I could easily abandon my tests and easily escape if my exploits attempts are discovered.
The second set of exploits would test the foundation of a multi-step exploit. My goal was to test how likely I could execute my entire plan without inadvertently disclosing it and putting it in jeopardy.
The third set of exploits would be to compromise any target. It would not be the actual approach or anything resembling it. I wanted to capture metrics on the speed of a successful compromise and the complexity of the exploit sequence. I would be rating how fast I would measure against a python attack.
Needless to say, I spent almost a year of weekends going to different locations with different permutations of my exploit tests. I wanted to ensure if anyone was tracking my exploits they would not see any pattern in the exploits themselves. Even my haircuts and style of clothing would differ to minimize the likeliness of my person being discovered. The end result was worth the annoyance.
I confirmed my entire kill chain would succeed even if parts of it could be stopped. I monitored the vulnerability databases and research papers and I was excited that my entire kill chain had not been discovered.
I was ready to execute the attack. I admit it was difficult to wait for the right time to attack. I distracted myself by planning how to hide my tracks. I also started contributing to open source projects that related to my kill chain. I would introduce purposeful bugs with two purposes: make my kill chain stronger but without looking obvious and make the discovery of a specific vulnerability come likely. Having a specific vulnerability announced and its potential havoc disclosed too would be my queue to strike.
You may be wondering how a vulnerability being disclosed would be my preferred strategy. I have been waiting to share that this vulnerability though easily resolved would be difficult to distribute. It would take months before it would be mitigated. This would give me months to attack high profile targets. The python attack would go down in greater infamy than any exploit in history.
And so, I waited and waited until one day I read this blog post.
"Security Research Company has published a critical vulnerability and its patch. SRC highly recommends that affected manufacturers immediately recall all their devices. Due to the nature of the vulnerability it is not feasible to distribute a patch in a software update without rendering the devices useless. Consumers beware of enabling any wireless or wired network communications if a recall option is not available. Failure to do so leaves the consumer vulnerable to multiple forms of identity threat. SRC stressed that the vulnerability is unlikely to be exploited due to the complex means it was originally discovered. That said, SRC cautions that this vulnerability not be taken lightly."
Time to strike…
This second edition was updated to include references to articles to aid in learning about cyber security.
Please consider leaving a review of this novel at http://getbook.at/BHC-PythonAttack.
Join the "Black Hat Chronicles" fan group to get updates on my writings, short stories, and upcoming novel. Visit https://goo.gl/forms/mtdRcj3vDJF3qkGo1 to join.
Stay secure,
Miguel
*Main Image Credit : The awesome piece of artwork used to head this article is called 'Python Dev Kit' and it was created by graphic designer Christina Young
[1]
Wikipedia has an overview of Stuxnet.
"Stuxnet." Wikipedia.
[2]
Time and time again the simplest attacks are the most effective.
Hern, Alex. "'Most cyberattacks come through simple failures' - security specialist." The Guardian: November 6, 2013.
Furthermore, the human is the weakest link and simple attacks are effective in exploiting individuals.
Santavy, Jon. "Social Engineering an Executive, an Employee, and a Grandma." Secjuice: June 11, 2018.
[3]
There are a number of popular hacker tools.
Raza, Ali. "8 Most Popular and Best Hacking Tools." HackRead: January 23, 2016.
This article gives an opinion of two operating systems preloaded with hacker tools.
Chavan, Rohan. "Kali Linux vs Parrot - Whats Different?" Secjuice: May 16, 2018.
[4]
Disgruntled employees retaliating with a cyber-attack is definitely possible. The FBI warned about this several years ago.
Higgins, Sean. "FBI warns cyber sabotage, extortion by disgruntled employees rising." Washington Examiner: September 27, 2014.
Recently a major corporation was a victim of a disgruntled employee.
Hull, Dana and Eidelson, Josh. "Musk says Tesla hit with 'extensive' sabotage by employee." Automotive News: June 18, 2018.
Main Image Credit : The awesome piece of artwork used to head this article is called 'Python Dev Kit' and it was created by graphic designer Christina Young.