IB fakapy 2019 – typical and not very

“But it’s not boring!” – this is the informal motto of the employees of our Solar JSOC cyber threat monitoring center (and I must say that 2019 fully corresponded to it). At the beginning of the new year, many people like to take stock and set new goals, but instead we decided to tell a few “horrors of our town” – the 2019 cases, which impressed even experienced analysts. The conclusion from these stories is only one: technology develops and evolves, and human laziness, negligence and carelessness are eternal.

Guest Wifi

When connecting customers to monitoring, we first of all ask for the most important information: critical accounts, domain groups, untrusted segments, white addresses, DMZ, critical subnets, etc. Untrusted subnets are just guest Wi-Fi, as well as contractor networks, test segments with permissions to permit any any, etc. … Usually we see that the possibility of interaction with such segments is absent or seriously limited, because controlling them very difficult, if not impossible. On the customer’s network, there was no possibility of such interactions, except for the authorization page in the guest network. We calmed down by adding a ban on interacting from Wi-Fi with TOR, C&C servers and other evil spirits, so that we would not be bombarded with operations that were not interesting to a potential customer (although we collected statistics on these incidents for summary reports). And on the third morning of the pilot project, we noticed an anomaly: the flow of events from the firewall increased 4 times!

They began to look for the cause of the “blockage” and, with surprise, found it in the segment of guest Wi-Fi. A certain host generated 4 million (!) Events per hour. And the events are quite interesting – connections on port 445 to random white addresses of the Internet space. Four million, Karl!

Having informed the customer about this, they began to wait for information about the host and the incident, since DHCP (it is the authorization server) was not connected to SIEM. After about 3-4 hours, the customer reported that the host is a mobile phone. To say that we were surprised is to say nothing. An ordinary mobile phone cannot generate such a stream of events. They began to find out the details, and it turned out that the mobile phone had nothing to do with it – someone just used one of the registered devices as a cover. It was not possible to find the true source of activity, and our client said that he was not interested in this case, so the activity had to be minimized. Nevertheless, we warned the customer’s specialists about the possible risks: since the activity (obviously malicious) comes from their addresses, they can, for example, get into the lists of C & C-servers of anti-virus vendors and receive complaints from law enforcement agencies (who knows what infrastructure this host will scan – after all, there may be KII, and scanning for vulnerabilities refers to incidents that need to be reported to GosSOPKA). After such arguments, the customer still decided to understand in more detail and fulfill our recommendations. And they were as follows:

1) close all ports except 80 and 443 (this turned out to be the right decision, because after 445 a scan on port 22 followed),
2) we introduce restrictions on the speed of the distributed Internet,
3) activate the UTM chips, including application control, and cut strange categories such as torrents, TOR browsers, detectable scanners, etc.
4) turn on the limit on the number of connections in the time interval.

The customer was never able to find out who this active Wi-Fi user was, but at least they blocked him with oxygen (and, most likely, the attacker went looking for the next available Wi-Fi.

A few months later, this pilot was successfully closed and transferred to the contract, but we still encounter similar cases in completely different companies, so the recommendations above can be classified as universal.

By default, or vendor sabotage

In parallel with the pilot connection to Solar JSOC monitoring, the customer commissioned a new UTM. Migration to it was phased: first transferred the ACL over the subnets, then the application policies. The dessert is the most interesting.

Everything happened according to the classics – on Friday night. The first line recorded mishaps in contacting customer infrastructure for TOR nodes, appearing as C&C in one of FinCERT mailing lists. Since the project was a pilot and the customer transferred all incidents to Low-criticality, there was no incident card provided for, in addition to notification by mail, an incident card. Therefore, the first operation from different hosts to one address, although it aroused suspicion among the monitoring engineers, was not escalated further. When the number of trips reached three, the guys sensed something was amiss and informed the analyst who took the incident to work.

First, the analyst contacted the responsible employees of the customer and suggested connecting hosts at the local log level to identify the source of activity. By the time of the discussion with the customer’s specialists, the number of hosts had grown to 7. The situation was very similar to the epidemic, but the antivirus on the hosts was working and silent, there were no active actions and host interactions on the network.

Connecting three hosts at the local log level also did not give an understanding of which process generated the activity. Anxiety grew, the only working option was the isolation of hosts with the parallel removal of a dump of RAM and the image of the hard disk. The analyst began to prepare instructions and at the same time decided to google the IP that the hosts accessed for availability in other mailings and incidents (because the type of activity that we observed was different from that described in the FinCERT newsletter). For the most part, the idea is quite miserable, but not this time.

Attention was drawn to the article in the title of which the IP address and the name of the UTM vendor were listed. To summarize the essence of the publication, the vendor bought an IP address that previously belonged to the TOR-node, which was featured on the FinCERT newsletter. And this is not only all! Further, the vendor decided to make this address default for the redirect of all suspicious calls from the infrastructure of his clients to potentially malicious addresses. That is, any connection with a strange IP address was interpreted by UTM as illegitimate and redirected to this miraculous address.

Having specified whether the anti-malware protection module is already on, and having received confirmation, the analyst and customer’s specialists exhaled.

P.S. An analysis of the failures that the UTM detected confirms that all 7 activities were False Positive.

We promised recommendations for each case, but here, perhaps, we will give only one: do not deploy on Friday. And warn all interested and sympathizers.


This leitmotif brings together a wide variety of cases. Take decommissioning for example. Often processes that have lost relevance in companies are simply forgotten: no one “parses” the old infrastructure, leaving the old virtual machines, servers and network accesses. At the same time, nobody monitors updates, antiviruses and events on these hosts, and even admins often do not know the owners of the systems. Therefore, after a while such infrastructure elements present not the most pleasant surprises. What does it cost only to send significant telemetry from an environmental organization on a project completed in 2005 to FTP servers of a non-friendly country!

Often no one deals with the maintenance of 10-year-old systems, although they continue to be used. For example, a password reset portal that uses the ancient engine and for the convenience of users looks at the Internet, or RDP, which the contractor needs to configure business applications and sticks out for 5-6 years.

The existence of such problems usually becomes known when:
1) the host was hacked, and encryption occurred with further extortion (there have been a lot of such incidents lately),
2) there is a migration from one solution on the perimeter to another,
3) we come to the pilot and collect the profile of open ports on the perimeter.

But there are also completely mythical situations: in 2013, the company built a tunnel with a contractor serving its financial system. The contract ended, but the tunnel remained, as it was made by the company in which the contractor rented the premises along with IT infrastructure. A new company took the same place and was surprised to find available addresses of other people’s infrastructure. Curiosity took over, and then temptation and thirst for profit. They dumped a database of counterparties and contracts to the noise – the benefit of the competition was interesting, but no one made noise in the victim company. The story lasted more than a year (it was not possible to trace further along the logs), but in the end, the investigation, the dismissals and the cherry on the cake are a criminal case.

AWOL, or Because it’s more convenient

The case as a whole is rather trivial, which cannot be said about the “implementation methodology”.

1) a pilot monitoring project at the customer;
2) connected sources on the perimeter, as well as between the corporate and technological segments;
3) admin on duty at the workplace and serving the closed network segment;
4) the acute desire of the administrator to work less, sleep more and do everything in comfort.

As I already said, when connecting, we ask the customer for various information, including white addresses, in order to collect statistics on connections to them from the Internet and thus form an external perimeter profile. Having created a rule that fills the list in SIEM, in about a week or two we collect statistics about all open ports on the perimeter, unload it to the customer, watch and fix together (while closing what is illegitimate). Gathering information for the profile, we periodically ran our eyes through the list, verifying that the ports are open to all or only some addresses on white lists. Attention was drawn to port 43388, which seemed to be unremarkable, but was broadcast in 3389 and the gray address, the owner of which was unknown to us then.

When checking it turned out that it is closed to our addresses. We thought that he was open on white lists, but during the day we did not observe any successful connections on him. Arriving the next morning, they again noticed that a packet of events had arrived overnight. This time we took a closer look at the source addresses and saw several sessions from Moscow with a total duration of more than 5 hours and a rather large number of short sessions from around the world. Then it became clear that the point was not that the port was accessible only to addresses from the white list, but that it opened only at night – from about 00.00 to 06.00 in the morning. Having excavated the logs from the domain and the antivirus (they had just been connected by that time), we were surprised to find that the address belongs to the administrator on duty, who should be at the workplace during this time interval! After analyzing the connections from his car, we found another interesting situation: every night, the port also opened (I think it’s not difficult to guess which one) in the closed dedicated segment. It is almost impossible to notice such activity on the fourth day of the pilot, by that time the number of allowed connections between segments is still more than open ports on the perimeter. Having informed the security guards about the situation, they connected the host at the local log level and made sure that the administrator was quietly escaping home from work. As it turned out, he lived almost in a neighboring house, and the remote connection, of course, became too much of a temptation.

Perhaps, if the administrator outlined the situation, he would be allowed to work remotely through SKDPU, provided that at the time of the accident he would be able to come to work within 15 minutes, and there would be no problems at all.


In reality, one of the main threats to information security is gouging on the ground. Therefore, minimize the risks:

1. Keep track of perimeter and firewall configurations.
2. Try to make the remote in the company managed (VPN through the terminal server). And if it already exists, control who uses it (by removing various RATs on hosts that now easily detect almost all anti-virus engines).
3. Follow the actions of privileged users: very often they lose their vigilance, believing that they have everything under control, and themselves make it easier for attackers to access critical data.

Similar Posts

Leave a Reply