Introduction
When making a choice in favor of connecting to the SOC, the company often considers the provider as a “safety net” in dealing with complex incidents and threats, which would be potentially difficult for it to cope with on its own. At the same time, it often happens that already at the stage of pilot testing of a service, bottlenecks or critical flaws in the existing strategy for ensuring the information stability of digital assets appear. That is why SOC is a collaborative “journey” where the company and the service provider go hand in hand, complementing and helping each other along the entire distance.
Figure: 1. Common company weaknesses
We have accumulated many years of experience in ensuring information security: both our own and our clients. And we want to share it with our readers. As part of this article, I will present several cases that were successfully prevented by our commercial SOC. A lot of useful things can be learned from them.
Case 1. "Proxy-regular"
The attendant recorded a network attack from the 10.XX250 address on the 10.XX70 host (YYru)
It turned out that the Kerio WinRoute Firewall software was installed on the 10.XX250 host. According to the host responsible for the operation, this software was used exclusively as a firewall. The host scan showed us the following:
The Kerio web interface is comfortably located on port 443:
Fig. 2. Kerio looking straight into the soul
However, the open port 3128, on which the http-proxy was running, aroused no less interest. Continuing the check, it was found that using the 10.XX250: 3128 proxy, it was possible to access the Internet without having to enter credentials. Internet access was carried out with external IP 89.XX18. Scanning the external IP address showed availability:
3128 / tcp - Kerio WinRoute Firewall proxy server port.
For this service, it turned out to be partially possible to use the Connect method:
Result: through a proxy on port 3128 / tcp, access from the Internet to the company's internal network is possible.
31415 / TCP - operation of the mrelayd software service
github.com/thinkberg/jta/blob/master/tools/mrelayd.c
Mrelayd works similarly to telnet-proxy. To specify the connection address, the "relay" method is used, which is indicated as a line like: "relay targethost targetport".
For example:
To proxy an ssh connection in this case, you can use the ProxyCommand (openssh) option or the connection options in Putty.
Bottom line: it is possible to access the internal network, including via control protocols.
This example illustrates, in spite of its apparent simplicity, the importance of correct proxy server configuration in a company. Indeed, otherwise, informational impact on internal digital assets is possible even in the absence of vulnerable services on the network perimeter and excluding variations in attacks with brute force authentication of remote control protocols.
Case 2. A router that could (actually not)
During the pilot project, the attention of the specialists of the operational monitoring center was attracted by the web interface of the network equipment accessible from the Internet. The default password did not work, but in the hope of beastly luck, an attempt was made to brute-force a 6-character password for the admin account.
Figure: 3. Looks easily accessible (using default accounts) The
attempt was successful, allowing further research. In the list of interfaces, among other things, a “patient” of the “PPTP client” type was noticed, and in its settings, credentials for connecting to a host in the company's internal network were carefully specified.
A successful connection was made with the found credentials and the external IP address of the device was determined
An external IP scan showed the presence of ports associated with cryptocurrency mining (which is a sign of a possible compromise of the system). In addition, the service on port 5000 / tcp attracted interest. The ill-fated 5000 / tcp hosts a vulnerable service that allows the launch of arbitrary scripts.
Operation example:
Fig. 4. Ping to internal services launched through the web interface
. Fig. 5. Output of the / etc / shadow file
It would seem that this is more than enough, but as part of a further check, it was found that the running monitoring service Cacti on 79 / tcp used the default access password.
Figure: 6. Devices on monitoring
The fact of accessing Cacti also allowed us to obtain information about the collection of logs and the SNMP community:
This example once again raises the question of the already boring problem of using credentials to access systems that do not comply with the password policy adopted by the company.
Case 3. Pentest vs SOC
More and more often, it is a good form for companies within the framework of SOC MTC testing to combine a pilot service project with a regular audit of information systems in the pentest format.
A modern SOC has the ability to detect, in accordance with the SLA, both the facts of the initial compromise of the system, and further attempts of a potential "attacker" to gain a foothold in the system, increase privileges and develop an attack on hosts already inside the corporate network. For this purpose, the audit policies for Windows / Unix systems of the customer and other available information security systems are configured accordingly. The collected security events are processed based on the developed correlation rules, which allows the SOC analyst to effectively detect and respond to potential incidents.
Figure: 7. For an ordinary pentester, the first round of "counteraction" with SOC ends very quickly.
After that, by way of concessions, turning a blind eye to the contractor's activity, clients suggest that the hired pentest specialists continue their work. This once again underlines the effectiveness of the SOC - we immediately calculate the activities of the pentesters hired by the company to check the security of the infrastructure. The question of the effectiveness and feasibility of using SOC disappears immediately.
Below is a short case study with one of the companies:
As you can see, all the actions of the "attacker", including the moment of his initial connection to the network, were identified and presented to the company.
An account compromise, the IP address of a potential attacker, and the fact that a pentester installed malicious services on the customer's hosts were identified. In the event of a real incident, all the information collected would be more than enough to respond appropriately and protect the company's digital assets.
And as a conclusion
I would like to note that the description of real SOC cases, like nothing else, should allow companies to understand the importance and expediency of using such a service.
Competent setting up of collection of security events, their analysis, writing of correlation rules suitable for the company, enrichment of information security events by means of cyber intelligence platforms projected on real incidents - make it possible to understand and evaluate the future efficiency of connecting to the SOC provider.
It is necessary to seriously understand that certain information security tools provide protection against private threats, however, they do not give a complete picture of what is happening “at the border”. SOC, bringing together skilled people, innovative technologies and structured processes, provides comprehensive protection of the organization from cyber threats in real time.
For example, as part of the MTS SOC, we agree with customers on the final list of connected source systems and correlation rules. Together with the protected company, we connect via an organized and customer-provided access tunnel to the source systems, set up a secure connection between them, the company's log collection server and the SOC system in order to transfer logs from source systems, transfer logs to the company log collection server and from it to SOC system in real time.
Figure: 8. Scheme of connecting the customer to the SOC provider
The SOC team, together with the company's employees, adapts the rules for detecting information security incidents, profiling network and host activity to minimize false positives. Additional capabilities can be control of external perimeter vulnerabilities and investigation of information security incidents.
Based on the results of the investigation of incidents, a report on the work done is formed. The SOC team, in addition to analyzing the incident and establishing the source system and causes, forms a set of technical recommendations to prevent or reduce the likelihood of similar incidents in the future.
Authors of the article:
Senior expert of MTS SOC Dmitry Berkovets and head of information security products of the #CloudMTS provider Alexander Karpuzikov.
Vacancies
If you want to join the #CloudMTS team, we have new vacancies:
Network engineer
UI / UX Designer
Golang developer
DevOps engineer