Geekly Articles each Day
📜 ⬆️ ⬇️

One quarter from the life of SOC. Three uncounted incidents

For me, as an analyst, the most useful and interesting reports and articles are those that highlight the practical aspects of information security and give concrete examples of incidents and methods for their detection and investigation. Therefore, today's article is devoted to several interesting cases that we have recently encountered in Solar JSOC.

Such necessary torrents ...


In one of our clients, all network activity of various applications is subject to strict profiling and control. Outgoing network activity of applications is monitored at the proxy level, and detection of network activity from a new user-agent is considered an information security event. In this case, the Solar JSOC 24-hour first monitoring line can either escalate it to the analyst responsible for the customer, or independently alert the customer on the route established for this type of incidents. The choice depends on the type of network activity, its suspicion and other related information.

It is worth noting here that tracking the user-agent is not a highly relevant scenario, since changing the agent being reported is not difficult. But lately, complex solutions like ngfw on indirect grounds, such as the composition of the package, header features, frequency, end servers, responses for outgoing requests, etc., are able to determine not the translated agent, but the real application.
')
As part of the investigation, the first line organizes the collection of the maximum amount of data on the incident: information about the car, all users authenticated in the last 24 hours, traffic volumes within the network session of this software, its duration. In the presence of local logs, information is collected on processes launched on the host.

On April 17, 2017, at about 3 am, a successful external connection of one of the remote administration tools was recorded from a working laptop of a technical support employee. The technical support department is the only one who is allowed to use this type of user agent, but in this case, instead of the standard tool, the utility TightVNC was used. The laptop was not connected to Solar JSOC, so first-line analysts could not collect local machine logs and escalated the incident to the second-line duty analyst, while simultaneously preparing an alert to the customer via email.

The following is a chronology of events:
03:08:02. Incident.
03:26:00. Alert by a first-line specialist on-call analyst by phone.
03:29:00. Coordination with the customer to connect the machine at the level of the local OS logs.
03:32:48. Notification from the 1st line in the direction of the Customer.
03:48:00 Connecting the machine to the SIEM system.

Thanks to the pre-configured advanced audit on all workstations (including mobile) and the customer’s servers, it became clear that the activity occurred as a result of downloading and running the tnvserver.exe process. Extended logging helped us identify the parent process, which we customize with customers on a mandatory basis. They are a torrent client that the antivirus did not consider malware.


The general chronology of events is as follows:

The situation with the so-called pseudo-useful software is very difficult, as proving its “malware” is quite problematic, although most of these utilities collect statistics on the user's work on the host, and some are able to run additional components and execute remote commands. However, at the same time, pseudo-useful software can simultaneously execute its main purpose, for which it was downloaded, and the “malicious” functions can be in a state of hibernation for a while or be added in subsequent versions when updating.

To identify such programs every year more and more difficult. If earlier markers were obtrusive advertising, a huge number of banners, user complaints and a curve code, then today any free product developed by “enthusiasts” can have these “features”. Typically, such programs offer to say music or movies, speed up your computer, clean the registry, download torrents, and more.

Part of antivirus solutions can detect such products as not-a-virus, that is, software that is potentially dangerous for the user, but performs useful functions. Another part of the antivirus does not respond to them.

The danger of pseudo-useful software is that on the overwhelming majority of workstations and on home computers it behaves completely normal, performing its basic functions and sending telemetry to developers. But when such software enters an infrastructure that is interesting for intruders, for example, a large company, its malicious functions are activated or components that allow remote execution of commands or organization of a remote administration session are downloaded. Further, such a host is put up for sale on the darknet as a point of entry into the company's infrastructure.

Further schemes of work of malefactors are various, but come down to theft of money and / or valuable information.

Instead of morality in the finale of this story I would like to give a few recommendations:

  1. Limit the possibility of direct connections through firewalls for users, use proxy servers. They have a categorization that allows, based on traffic or addresses, to identify the use of remote administration tools.
  2. Use antivirus software that can detect not-a-virus.
  3. Hold comprehensive security awareness training among users.
  4. Limit user privileges on workstations. In this case, it would help prevent the installation of both the main software and additional packages.
  5. If possible, adjust the software installed on the hosts, including the restriction of user rights (prohibiting a local administrator).
  6. Aggregation of reputation databases and their integration into the SIEM system will allow detection of undetectable malware samples in the infrastructure, the use of TOR, remote administration tools, etc.

Service Account Control


The second case concerns the use of legitimate tools in the work of IT and information security as a tool for penetrating critical infrastructure.

Solar JSOC employees received a request for assistance in investigating an incident involving an attempted theft of money through the payment system. The company was not our client, but knew about our services.

At the first stage of the investigation, the source of information for analyzing the incident was the servers where the electronic details of the payment system were stored. We connected these servers at the level of local logs of Windows OS (the maximum storage depth was 2 months for the System Event Log, Security - a week)

As a result of the authentication analysis, successful sessions from a server located on the perimeter were identified. From this server, connections to the studied hosts under the service account (techuser) were periodically established. Typically, this account was used for IT monitoring tasks in a company infrastructure.

At this stage, we have connected additional sources:

It turned out that it is impossible to analyze the local host server logs due to their cleaning, but when analyzing the image of this host in the restored and decoded wtmp file (records data in the input and output from the system), authentication records were found under the root account for several weeks before the incident.

Also on the SRV were found traces of software used by attackers to penetrate the infrastructure - software packages nmap (system scanning and vulnerability detection) and medusa (intelligent password recovery system).

When analyzing logs of inter-segment firewalls, from the first authentication on the SRV host using the root root to the time of the incident, multiple attempts were made to establish connections from the server to various company resources using the smb protocol. Most likely, the goal was password or other information relevant to penetration.

This can be visualized with HPE ArcSight internal tools:


Then significant (over 10 MB) sessions were recorded using the smb protocol from the SRV host to the compromised servers. They were performed at the same time as authentication events from local logs. Most likely, the password for the techuser account was compromised by the successful exploitation of the smb protocol vulnerability on the host. The vulnerability allowed pass-through authentication in the system under the Windows service account and compromise account passwords through the lsass.exe process.

Next, under the techuser account, a system service was installed that performs the functions of remoteshell.

The main features of this software are:


For two weeks, the attackers used this software to remotely manage compromised machines and steal key information, including payment system details.

After we restored the chronology of events and investigated the malware detected, it’s time to assess the scale of the disaster:

The companies were given recommendations to minimize risks and, in particular, to work out the issues of closing the following channels of an attacker’s access to infrastructure.

Like an apt ... or no?


The next case, identified in the framework of the pilot project Solar JSOC, looks very unusual, since by all indications it should be about the APT - spoiler alert! - but not really. So, given:

At the start of the pilot project, when connecting infrastructure sources, a significant part of the incident detection scenarios starts working immediately, without any additional efforts. These scenarios, among other things, include calls to potentially dangerous hosts on the version of various reputation databases aggregated in Solar JSOC.

The script works according to the following principle: There are several active sheets - a sheet with ip-addresses, a sheet with domains of 2-4 levels, a sheet with full links to malicious objects. The special script normalizes various reputation bases, leading them to a single mind. Then, each rule works with different fields either, checking for occurrences of events recorded on firewalls with activelist strings by the target address fields, either the request url host (target host name), or the request url.

When connecting the border firewall, calls were made to known potentially dangerous resources (IP addresses of C & C servers), which could indicate that the company's internal resources were infected with malware.

For each drawdown, a detailed analysis of the situations was carried out. We collected local operating system logs from hosts and identified the processes that initiated connections to external addresses.

One of the potentially infected hosts turned out to be the workstation of the assistant general manager of the company. As a result of investigating the machine, traces of malware were found on it, including spyware Mipko Personal Monitor (MPK).

Spyware MPK was installed on AWS from under the AWS \ Serv account. In this case, the first entry of this account to the workstation was made several months before the installation itself.

Mipko Personal Monitor collected from the workstation information about the processes launched, desktop snapshots, as well as data from the keyboard, from the clipboard and active browser windows.

Control and collection of information was carried out in respect of two accounts: AWS \ serv and helper account.

Intercepted data every 8 hours sent to external resources:

Transmission facts were confirmed by events from the border firewall.

From the moment of the first login under the AWS \ serv account to the time of the investigation, the host recorded multiple incoming remote RDP sessions from various external addresses (an average of 10,000 connections per day).

The screenshots collected by MPK spyware showed quite curious activity from the AWS \ Serv account:

Also, as a result of analyzing the MPK logs, a file was found that contained more than 500 different external IP addresses that are accessible from outside via RDP, along with the connection credentials (login password).

Apparently, the AWS assistant was used as an intermediate machine for attacks on websites, theft of bank card data / credentials of users of these sites and transfer of funds from compromised cards and accounts, as well as cash through purchases. Apparently, the infected workstation was one of the network of compromised machines used by the attackers for their own purposes.

And now a little technology.

As a result of the study, the following illegitimate utilities were discovered (illegitimacy confirmed, including by the owner of the AWP).

During the localization activities of MPK, we received additional information:


In order to establish the functionality of this MPK assembly and determine what information could have been collected and transferred to third parties as a result of the operation of the malware, we received the following data from the assistant's automated workplace:

In the “C: \ Windows \ MPK” directory, log files were found that contained information about the software installation and configuration parameters: mpk_em_log.txt and * .dat. As a result of the analysis, the details of the installation and operation of MPK were obtained:


Following the investigation, the customer was issued the following recommendations:

  1. Perezalit operating system on the workstation.
  2. Change passwords from all accounts used on this workstation.
  3. In case the Service-Desk service connected to this workstation and entered its credentials there, it was recommended to change the passwords from them.
  4. Deny the white IP address and direct Internet access for this workstation. If the presence of a white IP address is a production necessity, then use increased security requirements for any remote connections to it:

    • Passwords increased resistance;
    • Frequent change of passwords;
    • Hard limitation of IP addresses from which any incoming connections are possible;
    • Monitoring the status of antiviral drugs;
    • Isolation of a workstation in a separate segment without access to the company's internal resources or with strict restriction of such access to specific resources.
  5. Check the entire infrastructure of the company for the presence of such spyware, remote administration tools, other unauthorized software.
  6. Monitor critical workstations and servers in the following areas:

    • network activity to known dangerous and harmful resources (in real time);
    • privileged account activity;
    • running processes;
    • changes to system directories and critical registry branches;
    • use of remote control systems;
    • viral activity;
    • malicious mailings to users;
    • anomalies in connection profiles to critical servers and workstations;
    • misuse of service accounts.

As you can see, there are not always cases of compromise of the machine and long-term presence of malware on it lead to hacking of the client's infrastructure. Sometimes intruders have their down-to-earth targets, and infected hosts are used only as a means to achieve them. But potentially everything could have ended much worse - the amount of “sensitive” information among the employees of such a link is usually large, and its leakage can cause serious damage.

In this article I covered only three of the many cases that we see in the JSOC. Incidents happen daily, mostly routine, but there are also interesting specimens. Considering their number, I think the second series of interesting cases from the life of Solar JSOC will be released soon.

Source: https://habr.com/ru/post/333816/

More articles:


All Articles