Get best of the week

Investigation of information security incidents in the wild: unexpected sources of information

image

A lot has been written about the investigation of computer incidents, or Digital Forensics, there are many ready-made hardware and software tools, the main artifacts of operating systems are well known and described in manuals, books and articles. It would seem that it’s difficult - read the manual and find the required. But there are technically difficult cases when the analysis of those very well-known artifacts does not provide enough information to restore the chronology of events. How to be in this situation? We analyze it with real examples of our investigations.

Why is there a general lack of basic artifacts? There may be several reasons:

  1. The infrastructure is not adequately prepared for full monitoring and response to events (we wrote about this here )
  2. , ( Digital Forensic)
  3. , ( – , MFT-).

Thus, if the infrastructure is large and diverse, the incident developed for a long time, and the attacker is a “shredded kalach,” additional sources of information are needed to disclose all its actions and restore the chronology of events.

Depending on the situation, SIEM systems, analysis of Netflow network flows or raw traffic (although in reality in 90% of cases this is not possible), as well as unusual artifacts that relate to any third-party software, by coincidence, may come to the rescue. in the customer’s infrastructure.

It is on the last type of artifacts that we will stop.

Ivanti Endpoint Manager (formerly LANDESK Management Suite). IT Asset Management System

www.ivanti.ru/company/history/landesk

Connecting to the monitoring of one of our new customers, we detected in his infrastructure the cleaning of event logs on one of the servers, while there were no other manifestations of malicious activity in the SIEM system. During the analysis, it was found that the server was compromised, and the attacker used special equipment to go unnoticed. It consisted of the following:

  1. Security log events were redirected to a separate temporary file,
  2. an attacker performed the necessary actions,
  3. events are redirected back to the Security log,
  4. temporary file was deleted.
  5. Profit!

As a result, despite the fact that the Security journal was set up appropriately, it did not contain any events related to malicious activity, while it itself looked untouched.

After a short analysis, we found out that the attacker has been “living” in the infrastructure for about 2-3 years, which made it possible to compromise all key servers. In such cases, the value of any additional sources of information increases, since some basic artifacts are either frayed or uninformative and do not allow a complete picture of the incident.

In search of additional sources of information, we conducted an oral inventory of services and systems used in the infrastructure and found that, together with the implementation of our monitoring, the customer began to deploy an IT asset management system
Ivanti Endpoint Manager.

Since the system was still unstable (events from agents were not partially sent
to the server), we were unable to centrally view events from the hosts on the server. Nevertheless, having decided to search for artifacts stored by Ivanti Endpoint directly on the host, we found that this software stores information about process launches locally in the following registry branch:

HKLM \ SOFTWARE \ Wow6432Node] \ LANDesk \ ManagementSuite \ WinClient \ SoftwareMonitoring \ MonitorLog \ < The path to the executable file>

The following information is stored in the corresponding keys:

  • first start time (in FILETIME format)
  • last run time (in FILETIME format)
  • number of starts
  • user with rights of which the executable file was launched


Ivanti Endpoint process launch artifacts

Thanks to this information, we were able to determine the time of the attacker's appearance on some systems that we did not know about before. In addition, part of his toolkit was disclosed based solely on the name of executable files.

Citrix NetScaler System for providing access to corporate resources and applications

www.citrix.com/en-us/products/citrix-adc


Citrix NetScaler Workflow

Another interesting investigation. An attacker entered the company’s infrastructure through a VPN. He worked in the UTC +8 time zone. After authentication, it behaved quite aggressively (actively scanned internal subnets using the mask / 24 and / 16), as a result of which, in fact, it was noticed.

The VPN was configured on the Citrix NetScaler Enterprise Resource and Application System. Having studied its logs, we were able to establish the time of the first “visit” (read the date of compromise), the accounts of employees used by the attacker (by the way, more than 5 accounts were compromised) and the IP addresses of the proxy servers from which he worked.

The investigation itself ended successfully: we managed to establish a source of compromise - it turned out that the internal system for resetting credentials accessible from the Internet was subject to SQL injection.

But now I want to note something else: after passing VPN authentication on Citrix NetScaler, all HTTP user requests were successfully logged. The attacker probably either did not know this, or confused his network interfaces and sent his own queries to search engines through the customer’s corporate network. This allowed us to obtain information about the systems of interest to the attacker, his competencies and the tools used.


Citrix NetScaler log file


Information that an attacker was looking for through Citrix NetScaler


Information that an attacker was looking for through Citrix NetScaler

Secret Net Studio. System for protecting information from unauthorized access

www.securitycode.ru/products/secret_net

One fine day, a ticket with an suspicious authentication incident fell on our first line under the account of an IT employee of the company on the administration server at night (the employee was on vacation at that time, he had a VPN did not have). Architecturally, the administration server was located in a separate network segment along with several other key servers of the company (including the Secret Net server), and events to our SIEM were received only from the administration server itself (unfortunately, customers do not always agree to connect all potential sources )

The first line, processing the ticket and collecting information about what happened after the authentication, stumbles upon various suspicious process launches (non-standard paths, binary file names in one letter) and mstsc.exe launch, indicating a possible RDP session.

Realizing that this was a potential compromise, we requested images of all servers
and began their analysis. Opening the first image (Secret Net server), we received a “big surprise” as a present: the System, Security, and Application logs were deleted, and removed so that even recovery attempts were unsuccessful. It was only possible to compare that the entries in the SecretS server TerminalServices logs coincided in time with the launch of mstsc.exe on the administration server, which means that the attacker was definitely on Secret Net. Analysis of the remaining servers also failed.

As a result, we found ourselves in a situation where it is known for certain that the attacker is there (he definitely did and started something), but we don’t have host logs, because the traces are deleted,
and there are no network logs, because all the servers are on the same subnet.

A solution was found even from this situation. The Secret Net system is very versatile and consists of many components, both kernel level and user level. After analyzing each log file recorded and saved by various components of Secret Net, we came across several excellent artifacts left by file control. When we put everything together, we got information about the actions of the attacker (he really was on every server from this subnet), and about his tools.

By the way, the information received helped to completely get rid of the presence of an attacker in the infrastructure.


Scheme of an attacker working through the Secret Net Studio server Secret Log Studio


file control file

KVRT. Free antivirus tool

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

We were contacted for help in investigating an incident related to outgoing malicious activity (botnet and miner activity) from the public addresses of the company. Having received the images and logs of the system, we began the analysis and found some artifacts indicating a compromise of the organization’s public web service and the malicious files left. Unfortunately, this was not enough to answer all the questions asked by the customer: among other things, we did not find file traces of the miner, although there was not much time between fixing malicious activity and our investigation.

Returning once again to the artifacts and logs, we drew attention to the traces of several free antivirus scanners. It became clear that the files we were missing were encrypted and quarantined, and the timestamps of the file system were safely erased.

Among the scanners used was KVRT, which detected some malicious files and quarantined them. The standard location of quarantine files is C: \ KVRT_Data \ Quarantine, and decrypting them is very easy: a simple XOR with a well-known key is e2 45 48 ec 69 0e 5c ac.


Decrypted KVRT quarantine

As it turned out later, the IT administrator still managed to scan the system with free antivirus scanners before our arrival, despite the recommendation not to touch anything.
As a result, quarantined files helped close gaps in the chronology of events and answer all questions.


Each investigation is always something unusual, unique and versatile. Yes, there are known artifacts of operating systems, but before the investigation begins, it is difficult to predict the completeness of the information that can be obtained after their analysis. Therefore, before a technical investigation of the incident, we recommend that you take an inventory of the software and systems and not be lazy to study them as a possible source in the investigation.

More articles:


All Articles