It's a tested hacker strategy: hit when you are least likely to be detected.
Like Thanksgiving, Christmas, or any national holiday.
Let's look at a real-life example of this and how a holiday can help a hacker. Here is one organization's story.
Hacker waits to hit on a holiday when security staffing is low
When Timehop announced a breach of 21 million records during summer 2018, it posted an hour-by-hour timeline of the attack and the company's incident response.
In that timeline, the company revealed that the hackers specifically waited for the 4th of July holiday to execute an attack.
And as it turns out, the decision to strike on a national holiday granted attackers more time to work without detection.
How the breach started
Timehop says the attacker gained initial access to its systems by compromising an employee's credentials, and then the hacker created their own administrative user account in the system.
The attacker then checked back occasionally but found no personally identifiable information (PII) available. A table on Timehop's "users" was still empty at that point.
On June 22, 2018, the hacker discovered that the "users" table was in use, had been populated with PII, and that his credentials gave him access.
After doing some reconnaissance, the hacker logs out.
And waits. And waits some more.
Then, it is July 4th.
The company's employees, like the rest of the United States, are out of the office for the national holiday. That helps ensure the success of this attack, as you will see.
July 4, 2018: the cyber attack begins
The hacker logs in at 2:04 p.m. on the 4th of July, and here is what happens next, minute-by-minute.
- 2:04 p.m. - [The Unauthorized User] logs in and begins to restore an existing snapshot of the database containing the Users table into a cluster they created, called 'Reusers.'
- [The Unauthorized User] continually checks alarms and monitors while the restore process is progressing.
-
2:43 p.m. - [The Unauthorized User] resets the password to the production Users database.
-
2:43 p.m. - Internal alerts report the ‘Reusers’ database is available.
-
2:44 p.m. - [The Unauthorized User] initiates a deletion of the ‘Reusers’ cluster
-
2:49 p.m. - Internal alerts report the ‘Reusers’ cluster is closing down.
-
2:50~4 p.m. - Massive spike in database reads of the Users production cluster is reported by internal alerting tools. Timehop application users are reporting black screens.
-
4:04 p.m. - Internal alerts report the service being down. A Timehop engineer investigates and tries to restart the database.
-
4:13 p.m. - The Timehop engineer discovers that the password has been changed.
-
4:16 p.m. - The Timehop engineer discovers that the database, while still password protected, is not behind a firewall and can be accessed by anyone with the password.
-
4:23 p.m. - The Timehop engineer resets the password to the database, and services start to come back up.
July 5, 2018: incident investigation and response
- 6:09 a.m. - [The Unauthorized User] logs in using the API access key on [Employee]'s account and lists Cloud Computing Environment users, and logs out.
- 12:10 p.m. - Timehop engineers begin investigation into the event.
- 12:30 p.m. - Timehop engineers reviewing logs recognized suspicious patterns and conclude that we had been attacked. An incident is declared.
Did you catch that?
The diagnosis time from a serious investigation of the event to recognition as a cyber attack was just 20 minutes.
But that diagnosis was delayed by a day. It wasn't until enough engineers were back in the building on the 5th of July that they put their heads together and made the diagnosis.
As a result, diagnosis took about 22 hours.
That was nearly an extra day's worth of time for the attacker to have access to the company network.
Something to keep in mind when the IT security team is (mostly) out of the office on a holiday.
