Story of an investigation, or how DLP system revealed targeted attack

12.09.2017

Story of an investigation, or how DLP system revealed targeted attack

In their posts, Solared JSOC and Solared INsight analysts often say that even the combined use of the variety of protection tools available on the market will not stop an attack if a company treats each security system’s findings separately. In most cases, an attack, unless extremely primitive, can only be detected by reviewing data aggregated from different sources.

Below is an example which highlights this fact based on a story of one attack that was nearly left unnoticed.

Everything began as usual: we commenced an implementation project for a customer and in less than a week, when we were still configuring the system in line with the customer's requirements, Solared INsight detected a breach of the core information security policy: some confidential documents were regularly being sent to an external email address XXXX@icloud.com. The documents contained rather sensitive information: customer's financial indicators, product datasheets, etc. but the message body was always empty. In addition, the suspicious address was never accompanied by other addresses in the "To:" field, while no messages were received from the address in reply. As a result, we suspected that somebody was sending confidential documents to their personal mailbox. In our projects, we have faced diverse and sometimes absurdly naive attempts to steal confidential information. However, to be honest, this primitively straightforward effort confused us to some extent. Who could be so foolhardy to send sensitive documents to an external mailbox, while assuming that a DLP system was used at the company?

We quickly found out that there was more than one violator, since multiple employees sent messages to the mailbox, and we grouped all violators (about 20 persons) in a list, with some sending only one message, and others sending two or three. When investigating such incidents, the first step is to build a connection graph.

Our experience shows that in such cases there is always something that connects insiders. It's so certain, almost like a rule, that no connection may be deemed abnormal. However, according to Solared INsight findings, senders of the suspicious messages worked at different business units and contacted each other rarely and on business-related matters only. The fact that the connection graph revealed no anomalies surprised us, considering the straightforward nature of the attack. Therefore, we decided to search for other anomalies.

During the second stage of our investigation, we tried to find suspicious cases of behavior by violators and configured an incident-specific policy: those employees who sent documents to that address were automatically put on a watch list. We were even more astonished when the list began to be filled with many law-abiding and loyal employees!

At that moment, the customer ran out of patience and decided to look at the messages in person, only to detect something even weirder. No messages were found on either servers or senders' workstations, with all traces being deleted, except for the Solared INsight DLP archive, which kept all communication history. As a result, we started to realize that we probably faced something more intricate than just insider actions. The DLP system did its job well: it detected the leakage and analyzed the environment, communications, and employee actions. So, it was time for other tools.

We supposed that the messages were sent (and traces deleted) not by employees, but malware probably injected into the customer's systems as part of a targeted attack. Therefore, with the customer's consent, we submitted the case to Solared JSOC for analysis and investigation.

Analysts started to monitor workstations from which the messages were sent. However, although OS logs usually contain all required details, no information about launched processes was available: security logs were cleaned on all workstations right after the latest bunch of messages was sent. The only clue that helped us to get on the perpetrator’s track was the fact that a system log was left uncleaned and showed evidence of a strange service launch. It turned out that we were facing a zero-day virus that ran on workstations as a service rather than a process.

When we saw this abnormal service, we extracted the respective malware body and ran it in a sandbox to observe what would happen, with Process Monitor, Wireshark, and other utility software logging all network and process related anomalies.

We found that the malware consisted of several modules: the first was a typical keylogger and screenshot maker, while the second one provided remote access and the third copied documents used by employees and sent them during night hours to the mailbox, which alerted the DLP system. The virus never sent more than 50 MB at a time and it seemed that the cybercriminals intended to not only infiltrate the customer’s infrastructure, but also remain undetected for as long as possible, with the malware secretly deactivating antivirus software right after installation. As a result, we intercepted traffic going from an infected host, parsed it, and identified the IP address of a server with which the virus communicated.

During the next stage, we analyzed what registry entries were made by the virus, what libraries were changed, and where it was launched from. Based on our findings, we then performed a massive scan of the customer's entire infrastructure. Despite the fact that information was leaking through approximately 20 users, the virus was found in its latent state in about half of all of the customer's machines. The malware was removed, its communication and remote control channel was blocked, and users were instructed to change their account passwords since the old ones were compromised.

The ability to remain undetected and bypass the exact protection tools installed at the company, and document stealing as a core function, suggested that a targeted attack had been performed on the company. The customer also realized how serious the situation was and submitted all findings to law-enforcement agencies.

This case demonstrates that even DLP logs may sometimes provide evidence of a targeted attack if you watch any anomalies in user and system activity closely. This is why we always pay great attention to such things. Often, anomalies tell us of nothing illegal, but sometimes proper analysis may provide a security officer with a full picture that disparate protection tools cannot give. Therefore, remember to always be careful and never disregard anything that seems strange, collect all available information, and may the force be with you :)