The story of an investigation or how the DLP system revealed a targeted attack.
Solar JSOC and Solar Dozor analysts in their articles often say that even the whole variety of protection tools on the market will not protect a company from an attack if it considers the data of each system separately. Most often, the attack, if it is not quite primitive, can be identified only by combining data from various sources.
Today we want to talk about another example confirming this truth. Under the cut - the story of one attack, which almost went unnoticed.
It all started quite standardly: we launched the implementation project at the next customer. Less than a week later, when we didn’t even have time to properly adjust the system to the requirements of the company, Solar Dozor revealed violations of the most basic information security policy: a number of confidential documents regularly went to the external address of the form XXXX@icloud.com. The documents contained rather serious information - financial indicators of the company, technical data on products, etc., but the body of the letter was always empty. The suspicious address was met solely alone, never adjoining to other addressees in the "To" field. There was not a single letter that came back from this address. It was suggested that employees drop the most interesting documents on their personal email. Honestly, although the projects have to deal with very different, sometimes quite absurd in their naivety, attempts to bring out confidential information, such a “frontal attack” has caused some dismay. Easy to send documents with critical information to an external box, knowing that the company uses DLP?
')
It quickly became clear that the offender was not one - a number of company employees sent letters to this address. We have compiled a list of all violators, he numbered about 20 people. In this case, someone managed to send only one letter, someone - two or three. The first step in investigating such incidents is to build a linkage graph.
Connection graph in Solar Dozor
Our practice shows that in such cases, the perpetrators of the leak always have something in common. This rule is so reliable that the very lack of communication between insiders can be considered an anomaly. However, Solar Dozor analytics showed that the senders of suspicious messages belonged to different departments, communicated with each other very little and exclusively on work issues. The fact that the construction of the link graph did not reveal any anomalies was surprising with such a frontal attack. We decided to look for other anomalies.
The second step was an attempt to find suspicious activities in the behavior of violators. We set up a special incident policy: employees who sent documents to this address were automatically sent to a special control group. Imagine our surprise when, seemingly quite “law-abiding” and loyal employees began to get in there massively!
The customer could not stand it and decided to personally look at these letters, and then the following oddity arose. It turned out that there are no letters either on the server or on the senders' workstations. All traces were removed, but since Solar Dozor keeps the entire history of messages, letters remained in the DLP archive. It became clear that we may be dealing with something more complicated than insider actions of employees. DLP fulfilled its task - revealed a leak, made an analysis of the environment, communications and actions of employees, it was time to use other means.
Our hypothesis was that the letters were sent (and deleted) not by employees of the companies, but by malicious software that may have been introduced into the company as part of a targeted attack. With the consent of the customer, we handed over the case for analysis to Solar JSOC.
Analysts connected to the monitoring workstations, which left the letter. Usually, the operating system logs can collect all the necessary information, but in this case there was no information in the list of running processes - the security log was cleared at all stations immediately after the last tranche of letters was sent, and there were no new shipments. The only clue with which we got on the trail of the attacker was that the system log was not cleared and recorded the launch of an unusual service. As it turned out, we were dealing with a 0day virus that acted on the users' machines not as a process, but as a service.
Having seen this anomaly service, we isolated the body of the associated malware object and launched it in an isolated environment in order to observe what was happening. Process Monitor, WireShark and other utilities carried out an additional collection of logs so that we could register all network and process anomalies.
As a result, the following became known about the malware: it consisted of several modules — one was a typical keylogger and took screenshots, the second provided remote access, and the third copied those documents that the user works with, and sent them to that external schedule at night mail, which alerted the DLP-system. The virus "merged" outwardly no more than 50 MB at a time - obviously, it was important for attackers not only to gain a foothold in the infrastructure, but also not to give out their presence for as long as possible. For the same purpose, it worked that immediately after installation, the malware, unnoticed by the user, deactivated the antivirus. We intercepted the traffic coming from the infected host, and, having disassembled it, set the IP of the server with which the virus communicated.
Then we could only analyze what records the virus makes in the registry branch, which libraries it changes, where it is written to autorun. According to the identified indicators, we launched a massive check on the entire infrastructure of the user. It turned out that, although the leaks were from about 20 users, the virus was found in inactive state in about half of the customer’s entire fleet. Malicious software was removed, the interaction and remote control channel was blocked, and users were obliged to change all account passwords, since the old ones were compromised.
The desire to go unnoticed, the ability to circumvent precisely those remedies that were installed in this company, finally, the theft of documents as the main functionality - all this suggested that we are dealing with a targeted attack on the organization. The customer was also aware of the seriousness of the situation, and all the information received was transferred to the law enforcement agencies.
This case shows that sometimes, if one is attentive to anomalies in the actions of users and systems, even DLP logs can indicate a targeted attack. Actually, therefore, we always pay much attention to this. Often, anomalies do not reveal anything illegitimate, but sometimes their analysis is able to reveal to the security person a complete picture that scattered defenses will not give. Therefore, be careful, do not pass by the oddities, collect all possible information and - may the force be with you :).
Today we want to talk about another example confirming this truth. Under the cut - the story of one attack, which almost went unnoticed.
It all started quite standardly: we launched the implementation project at the next customer. Less than a week later, when we didn’t even have time to properly adjust the system to the requirements of the company, Solar Dozor revealed violations of the most basic information security policy: a number of confidential documents regularly went to the external address of the form XXXX@icloud.com. The documents contained rather serious information - financial indicators of the company, technical data on products, etc., but the body of the letter was always empty. The suspicious address was met solely alone, never adjoining to other addressees in the "To" field. There was not a single letter that came back from this address. It was suggested that employees drop the most interesting documents on their personal email. Honestly, although the projects have to deal with very different, sometimes quite absurd in their naivety, attempts to bring out confidential information, such a “frontal attack” has caused some dismay. Easy to send documents with critical information to an external box, knowing that the company uses DLP?
')
It quickly became clear that the offender was not one - a number of company employees sent letters to this address. We have compiled a list of all violators, he numbered about 20 people. In this case, someone managed to send only one letter, someone - two or three. The first step in investigating such incidents is to build a linkage graph.
Connection graph in Solar Dozor
Our practice shows that in such cases, the perpetrators of the leak always have something in common. This rule is so reliable that the very lack of communication between insiders can be considered an anomaly. However, Solar Dozor analytics showed that the senders of suspicious messages belonged to different departments, communicated with each other very little and exclusively on work issues. The fact that the construction of the link graph did not reveal any anomalies was surprising with such a frontal attack. We decided to look for other anomalies.
The second step was an attempt to find suspicious activities in the behavior of violators. We set up a special incident policy: employees who sent documents to this address were automatically sent to a special control group. Imagine our surprise when, seemingly quite “law-abiding” and loyal employees began to get in there massively!
The customer could not stand it and decided to personally look at these letters, and then the following oddity arose. It turned out that there are no letters either on the server or on the senders' workstations. All traces were removed, but since Solar Dozor keeps the entire history of messages, letters remained in the DLP archive. It became clear that we may be dealing with something more complicated than insider actions of employees. DLP fulfilled its task - revealed a leak, made an analysis of the environment, communications and actions of employees, it was time to use other means.
Our hypothesis was that the letters were sent (and deleted) not by employees of the companies, but by malicious software that may have been introduced into the company as part of a targeted attack. With the consent of the customer, we handed over the case for analysis to Solar JSOC.
Analysts connected to the monitoring workstations, which left the letter. Usually, the operating system logs can collect all the necessary information, but in this case there was no information in the list of running processes - the security log was cleared at all stations immediately after the last tranche of letters was sent, and there were no new shipments. The only clue with which we got on the trail of the attacker was that the system log was not cleared and recorded the launch of an unusual service. As it turned out, we were dealing with a 0day virus that acted on the users' machines not as a process, but as a service.
Having seen this anomaly service, we isolated the body of the associated malware object and launched it in an isolated environment in order to observe what was happening. Process Monitor, WireShark and other utilities carried out an additional collection of logs so that we could register all network and process anomalies.
As a result, the following became known about the malware: it consisted of several modules — one was a typical keylogger and took screenshots, the second provided remote access, and the third copied those documents that the user works with, and sent them to that external schedule at night mail, which alerted the DLP-system. The virus "merged" outwardly no more than 50 MB at a time - obviously, it was important for attackers not only to gain a foothold in the infrastructure, but also not to give out their presence for as long as possible. For the same purpose, it worked that immediately after installation, the malware, unnoticed by the user, deactivated the antivirus. We intercepted the traffic coming from the infected host, and, having disassembled it, set the IP of the server with which the virus communicated.
Then we could only analyze what records the virus makes in the registry branch, which libraries it changes, where it is written to autorun. According to the identified indicators, we launched a massive check on the entire infrastructure of the user. It turned out that, although the leaks were from about 20 users, the virus was found in inactive state in about half of the customer’s entire fleet. Malicious software was removed, the interaction and remote control channel was blocked, and users were obliged to change all account passwords, since the old ones were compromised.
The desire to go unnoticed, the ability to circumvent precisely those remedies that were installed in this company, finally, the theft of documents as the main functionality - all this suggested that we are dealing with a targeted attack on the organization. The customer was also aware of the seriousness of the situation, and all the information received was transferred to the law enforcement agencies.
This case shows that sometimes, if one is attentive to anomalies in the actions of users and systems, even DLP logs can indicate a targeted attack. Actually, therefore, we always pay much attention to this. Often, anomalies do not reveal anything illegitimate, but sometimes their analysis is able to reveal to the security person a complete picture that scattered defenses will not give. Therefore, be careful, do not pass by the oddities, collect all possible information and - may the force be with you :).
Source: https://habr.com/ru/post/324488/
All Articles