Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content.
You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Managing your cookies

Our website uses cookies. You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button.

Necessary cookies

These are essential for the user navigation and allow to give access to certain functionalities such as secured zones accesses. Without these cookies, it won’t be possible to provide the service.
Matomo on premise

Marketing cookies

These cookies are used to deliver advertisements more relevant for you, limit the number of times you see an advertisement; help measure the effectiveness of the advertising campaign; and understand people’s behavior after they view an advertisement.
Adobe Privacy policy | Marketo Privacy Policy | MRP Privacy Policy | AccountInsight Privacy Policy | Triblio Privacy Policy

Social media cookies

These cookies are used to measure the effectiveness of social media campaigns.
LinkedIn Policy

Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Skip to main content

Never feel afraid to report a security incident

Red Team Lessons Learned Series – Episode 1

Never feel afraid to report a security incident

 

Introduction

In this series of blog posts I wanted to highlight some common patterns of problems I observed while working in cybersecurity with various organizations. I made most of these observations while working as a Red Teamer, but there are also things that occurred to me when working as an Incident Responder. Read on to ask yourself whether your organization could be affected by any of these problems – and if so – to think what could possibly be done about it.

Users and staff happen not to report security incidents

Based on my own observations from some Red Teaming operations, as well as some of the incidents I investigated when I worked at CERT, I believe there is a trend of employees ignoring signs of compromise or even deliberately covering up security incidents.
I am not talking about malicious insiders, but regular staff who are afraid that reporting a security incident could get them in trouble.

The ignorance of backdoors

One such example was an administrator who discovered our backdoor in his system. We knew he did, because we read his /root/.bash_history file. It clearly showed that he was manually inspecting (using common commands like cd, ls and cat) the directory structure created by the web server after we gained administrative access to it and we used its internal features to attain code execution as root (we created another instance of http server running as root, then added our backdoor into its internal task scheduling mechanism, which ensued in creation of a new directory structure under webserver’s /var/lib directory).
As per his own /root/.bash_history, after browsing those files, the admin manually stopped the entire webserver service, then set the service not to start with system boot anymore. So, it clearly looked like his attempt at responding to the incident himself. At that time, we already had system user credentials (including root) and SSH access. And we kept our access for a few more weeks, only because the administrator decided not to report the incident, while failing at properly responding to it himself. Our assumption is that he was afraid he could get fired for failing to do his job. He might have felt guilty, as in fact we would not had compromised that system, had he upgraded its software on time. While, in my opinion, he should feel more guilty for deliberately ignoring an incident like this.

Maldoc infection

Another example was an IT employee who got infected with a maldoc, as revealed in our forensic investigation conducted in response to a major incident we worked on at CERT. Once the employee realized that he was attacked, instead of disconnecting his system from the network and reporting the incident, he spent few hours trying to disinfect his computer with some free anti-malware tools he started downloading from the Internet. Meanwhile, as our investigation revealed, the criminals were already moving laterally. Few days later the entire network got encrypted with ransomware. Proper employee reaction, even after opening the infected attachment, could have prevented tremendous damage.

How often does this happen?

We could also question ourselves why not all users targeted in our Red Team phishing campaigns report phishing emails? Maybe some of them realize they got attacked, but – in case they visited the link/gave out their credentials/activated a maldoc macro – are afraid of potential HR consequences and chosoe to pretend like they did not notice anything suspicious?
It is not that hard to imagine a situation when an employee ignores an anti-virus alert on their desktop, simply because they BELIEVE it could be their fault, even when it is not? For example, we know many people use their work laptops for personal tasks to some degree, even if they know they should not – but often convenience takes the better of good security hygiene and best practices. A user seeing a sign of his system being infected could decide to look the other way, “cause it’s probably because I went on one of those websites I should not have”.
To find out how common these situations are, we cannot count on the bad guys sharing with us how many times they observe something like this. We will also not get this answer from the culprit users. It is, however, something that can be observed from time to time by your own Red and Blue teams.
In my opinion the problem is quite complicated, consisting of many aspects, especially psychological, cultural, and organizational.

Employees should never feel afraid of reporting incidents

Instead, they should be encouraged to do so through proper awareness and avoidance of blame-culture.

Share this article

Follow us on