Recently we detected return of reflection from 1434 port. The attack manifests in the form of Microsoft SQL Server responses to a client query or request via abuse of the Microsoft SQL Server Resolution Protocol (MC-SQLR), which listens on UDP port 1434.

MC-SQLR lets clients identify the database instance with which they are attempting to communicate when connecting to a database server or cluster with multiple database instances. Each time a client needs to obtain information on configured MS SQL servers on the network, the SQL Resolution Protocol can be used. The server responds to the client with a list of instances.

Attackers abuse SQL servers by executing scripted requests and spoofing the source of the query with the IP address of the intended target. Depending on the number of instances present in the abused SQL server, the amplification factor varies.

The attack presents a specific payload signature, producing an amplification factor of nearly 25x. In this case, the attacker’s request totaled 29 bytes, including IP and UDP headers, and triggered a response of 719 bytes including headers. Some servers may produce a larger or smaller response depending on their configuration.



In this section, we show how to check a host for an openly accessible service. All tests are performed using tools commonly included with standard Linux/Unix distributions. To verify the service is openly accessible from the Internet, the test should not be run on the host itself or the local network but instead from a different node on the Internet, for example a host on a cable/DSL line. In all examples, replace 95.141.xx.xx with the IP address of the host to check.

To check if an MSSQL browser service is openly accessible from the Internet, connect to the MS-SQL server using ‘netcat’ as follows:

$ netcat -u 95.141.xx.xx 1434
Then, press followed by .

An openly accessible MSSQL browser service will return a response like this:

ServerName;S16362421;InstanceName;MSSQLSERVER2012; IsClustered;No;Version;11.0.2100.60;tcp;49511;np; \\S16462341\pipe\MSSQL$MSSQLSERVER2012\sql\query;;
Otherwise, there will be no response.


If the MSSQL browser service is not needed, disable it. Otherwise, restrict access to trusted clients, for example by blocking incoming connections to port 1434/udp on the firewall.

Microsoft recommends:
“The SQL Server Browser service lets users connect to instances of the Database Engine that are not listening on port 1433, without knowing the port number. To use SQL Server Browser, you must open UDP port 1434. To promote the most secure environment, leave the SQL Server Browser service stopped, and configure clients to connect using the port number.”

SeFlow DDoS Mitigation

If you’re a victim of this amplification you need to contact your provider to get protected because is volumetric DDoS and your uplink maybe will not be enough to absorb it.

SeFlow Customers are already protected, we block this kind of attacks on our backbone and you will not receive packets.

Kind Regards

Intel/AMD BUG Spectre/Meltdown . Why my MyCore was not rebooted?

Intel/AMD BUG Spectre/Meltdown . Why my MyCore was not rebooted?

As you probably know, some days ago Intel and AMD released some information about vulnerabilities called Spectre e Meltdown (codes: CVE-2017-5715 CVE-2017-5753 CVE-2017-5754 ). Curious can find more information here

Most of service providers were forced to reboot their environment and you suffered a little downtime to patch the hypervisor. SeFlow is happy to announce that we do not need to reboot your VM because MyCore uses kernelcare technology that allows us to patch every kernel without rebooting it. What does this mean? Those hypervisors are already secure!

Now you need to secure your VM, to do this please update your kernel VM and schedule a reboot (you can do on night hours or when you prefer). After that you will be safe without more downtime.

If you have any doubts please not esitate to contact us and we will be happy to assist you.

Kind Regards