A little help with the investigation of an alert

1

We got a disturbing Suricata alert yesterday morning:

(#2404312) ET CNC Feodo Tracker Reported CnC Server group 13

Just a quick note about our environment - we have about a dozen Windows 10 Pro workstations. 1 Windows Server 2012 R2 server, which is our domain controller, SQL Database server and internal web server. The alert happened on our server IP:

Source: my.server.ip:80

Destination: 45.61.187.123:49786

I looked up the external/Destination IP on VirusTotal, and 15 security vendors flagged that IP as malicious. Then I did a ā€˜ping -aā€™, and the host/url that came back for that IP was: smtp20.shbgura.xyz. That URL seems pretty fishy to me. Just for the heck of it I plugged that url into VirusTotal, and no security vendors flagged that as malicious. So my 1st question is what the heck? Why am I getting 2 different results for the same destination?

Then I looked up the IP and domain up on Ciscoā€™s Talos Intelligence. ā€˜Sender IP Reputationā€™ is ā€˜Neutralā€™ and ā€˜Web Reputationā€™ is ā€˜Untrustedā€™.

I tried a few other IP reputation type sites and they reported as being benign if I remember right.

No new software has been installed on our server in the last week or 2 at least. I wanted to figure out what program/process reached out to that IP. But to my knowledge Windows Server does not keep a record of all network connections and their associated processes. What I did in hopes that the connection would happen again is download a program called TCPLogView and ran it. Thankfully it happened again. The bad news is that the process that made the connection was ā€˜Systemā€™. So I have no idea what do next.

Now, Iā€™m not new to IT, but Iā€™m very new to the whole security world and Suricata so please keep that in mind. Maybe thereā€™s an obvious thing I should do or check, but Iā€™m not thinking of it at the moment.

Just for a quick summary:

We got the following alert from Suricata twice yesterday:

(#2404312) ET CNC Feodo Tracker Reported CnC Server group 13

The source/destination IP:

Source: my.server.ip:80

Destination: 45.61.187.123:49786

The source IP is the IP address of our single, Windows Server 2012 R2 box which serves as an internal web server, SQL server, domain controller, file server, and QuickBooks server.

Yesterday was the first time I recall seeing that alert. We have about a dozen Windows 10 Pro workstations connected to the network. And about a dozen VoIP phones. A couple network printers. But nothing new on the network that I know of. I donā€™t know if I should be worried or not. I donā€™t have a background in security

As of right now, we havenā€™t received the alert since yesterday.

1 Like
2

Since you mentioned it was a web server and the src port is 80, Iā€™m guessing this is TCP. What were the TCP flags on the offending traffic (if Suricata was configured to log the packet)? The rule in question is an IP rule so this could have just been the web server responding to a connection attempt/scan (with SYN-ACK). Is that web server open to the Internet? If not, are you sure? Do you see anything in the web (IIS?) logs for the time(s) in question?

3

This is probably a false positive since the source port is 80 (your webserver) and the destination port is a randomly generated one.

This means that suricata alerted on the response packet, the malicious ip is probably scanning the internet and hit your webserver.

1 Like
4

Hi @dwharton and @IDSTower . Thank you for the help/info/replies! I think you guys are rightā€¦yes, the serverā€™s web services are open to the outside world on port 80. I was in minor panic mode when seeing that alert so wasnā€™t thinking real clearly.

@dwharton - I donā€™t know if Suricata is configured to log packets. Is this the same as configured to do full packet capturing? If so, itā€™s not configured that way. Would you recommend me turning this on going forward?

Iā€™ll check my IIS logs when I get back to work Monday morning. Iā€™m not sure how much detail is actually logged though - itā€™s a default installation - Iā€™ve never configured any logging on it.

Iā€™ll report back on my findings (or even lack of).

Thank you again guys!

5

An update. The alert came in once yesterday too. Here are the 3 corresponding entries in our IIS web server logs:

2023-03-09 01:15:19 my.server.ip.redacted GET / - 80 - 45.61.187.123 Hello+World - 200 0 0 193
2023-03-09 19:24:34 my.server.ip.redacted GET / - 80 - 45.61.187.123 Hello+World - 200 0 0 203
2023-03-12 18:59:37 my.server.ip.redacted GET / - 80 - 45.61.187.123 Hello+World - 200 0 0 177

Iā€™m not sure what to make of this. Judging from the other entries in the logs, the field that shows as ā€˜Hello+Worldā€™ here is the user agent.
I think the ā€˜200ā€™ field is the response, but I donā€™t know what fields the 0ā€™s are, or that last number (192/203/177).

Overall, Iā€™m not sure what this means, or if itā€™s good or bad.

6

This is just someone scanning the Internet looking for what IPs are hosting web servers. Iā€™ve seen the same thing from this IP over the past few days on webserver(s) I have open to the Internet.
The log fields are going to be dependent on the IIS logging config but ā€œGETā€ is the http method, ā€œ/ā€ is the requested path, ā€œ80ā€ is the destination port, ā€œHello Worldā€ is the user-agent, ā€œ200ā€ is the server response code, etc. The numbers on the end usually have to do with bytes transferred and/or response times.

This activity isnā€™t something to be concerned with but if this server doesnā€™t need to be exposed to the Internet, Iā€™d recommend firewalling it off.

Re: packet logging - check out the following suricata config section and options:

outputs:
  - eve-log:
      types:
        - alert:
            payload: yes             # enable dumping payload in Base64
            # payload-buffer-size: 4kb # max size of payload buffer to output in eve-log
            payload-printable: yes   # enable dumping payload in printable (lossy) format
            packet: yes              # enable dumping of packet (without stream segments) in Base64
7

Hi David,

Thank you for all the info.

Unfortunately I do need to keep the web server exposed - our clients need access to it.

I turned on those 3 settings that you show, and now Iā€™m getting extra stuff in my alerts. It seems that most of it isnā€™t readableā€¦at least for me. Iā€™m not sure what to do with it, but I guess at least itā€™s there in case I need it or someone asks for it.

Thank you again!

8

Hi JN,

While I know this doesnā€™t answer any of your questions (though Iā€™m assuming youā€™re considering the issue solved.) I did want to mention that I had identical traffic hit my webserver on the 9th, the scanner also tried a few more times over the next few days. When I saw the warning, it definitely concerned me, which led me here.

Thankfully, following what you were advised, I searched through my webserver logs and found they are the exact same as yours: 45.61.187.123 - - [12/Mar/2023:11:54:10 -0700] "GET / HTTP/1.1" 404 162 "-" "Hello World". Iā€™m assuming itā€™s looking for outdated and exposed http servers.

I mainly wanted to post this and say thank you for posting your concern, it let others find it and definitely put my mind at ease!

9

Hi catbirby,

Thanks for taking the time for sharing!