2

I have a server on AWS, GuardDuty started send me notifications:

*** "type":"Backdoor:EC2/C&CActivity.B!DNS",
*** {"domain":"libcurl.so","protocol":"UDP","blocked":false}
*** is querying a domain name associated with a known Command & Control server. ***

I've checked the server with all possible security tools and nothing found. With tcpdump -A I saw that my server send such kind of request about this domain. I have turned on auditd. But nothing strange was found.

My question is, how to determine, which process exactly send this request?

Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43
kbu
  • 255
  • 4
  • 14
  • 1
    If the server is compromised, you can't trust that something like `auditd` will work - it's already a lost cause. Read [how do I deal with a compromised server?](https://serverfault.com/questions/218005/how-do-i-deal-with-a-compromised-server) - but first, shut the server off so it stops attacking people. – ceejayoz Oct 12 '18 at 13:22
  • Sorry, but your answer can't help solve the problem and do not answer my question. Thank you. – kbu Oct 12 '18 at 13:24
  • It may not be the answer you *want* to hear, but it **is** the answer. – ceejayoz Oct 12 '18 at 13:27
  • Ok, we can suggest that the link above is the answer. But major question was: how do determine the process, which send DNS request? Any ideas? – kbu Oct 12 '18 at 13:36
  • @kbu You'll need to shut the server down, mount its filesystem to a new, uncompromised server, and start analyzing things. You'll first want to ask yourself if you regularly patch your servers (and any software on it, like web apps). – ceejayoz Oct 12 '18 at 13:40
  • This is a mail server and all patches installed when they are available. Nothing unnecessary is installed, all ports and daemons monitored – kbu Oct 12 '18 at 13:44
  • 1
    Your next step will probably be the auth log, weak passwords, or compromise of a machine used to administrate the server, like your own computer. – ceejayoz Oct 12 '18 at 14:14
  • Thank you all for your very helpful comments. The process was found with: auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET – kbu Oct 12 '18 at 18:42
  • This was a pyzor. Since a stopped communication with pyzor any requests to libcurl were stopped. – kbu Oct 12 '18 at 18:43
  • Another source of false positives can be `sshd` if port 22 is open and `UseDNS=yes`, which is the default on many Linux images. In this case **any** ssh scanner from a suspicious domain will trigger the `Backdoor:EC2/C&CActivity.B!DNS` finding. – Wolfgang Kuehn Aug 28 '21 at 20:28

2 Answers2

2

I'm afraid with normal packet captures there is no way of identifying the PID from the packets, because all you can see is what port the packet was sent from.

You can use netstat to identify who is using that port but DNS takes millisecondes so you have to be very lucky.

Systemtap can be used to find which process sent udp packets to dns using the example systemtap script :https://sourceware.org/systemtap/examples/network/who_sent_it.stp

Last solution provided by AWS : If you are unable to identify and stop unauthorized activity on your EC2 instance, we recommend that you terminate the compromised EC2 instance and replace it with a new instance as needed.

Laurent Richer
  • 21
  • 1
2

Official answer from AWS:

The GuardDuty team has confirmed this to be a false positive. The domain "libcurl.so" has been removed from the source threat intelligence list.

FYI: Passwords are not weak and other best practices were realized. OSSEC, Tripwire and other stuff is on the server.

kbu
  • 255
  • 4
  • 14
  • Side question: are you getting these notifications every 6 hours? In one of my environments, I have this same `Backdoor:EC2/C&CActivity.B!DNS` rule firing every 6 hours on one instance for a different (and similarly harmless) domain, even though the DNS queries to that domain are no longer occurring, confirmed by wireshark -- as if the incident is somehow "stuck" in Guard Duty. I'm curious if you are perhaps unable to capture it with tcpdump for the same reason. The console shows the last incident was weeks ago, but the events continue to fire. – Michael - sqlbot Oct 13 '18 at 11:46
  • Yes, it was every 6 hours – kbu Oct 14 '18 at 17:05
  • 1
    Thank you. Aside from whether `libcurl.so` is a false positive or not (this is subjective and I am inclined to disagree with that assessment -- the site seems harmless, but *accessing this site* could have been a sign of failing a penetration test because you are making a query that you should not have made) I am curious whether you will continue to get these notifications. There may be a bug in Guard Duty, continuing to notify when nothing is actually continuing to happen. No response on the official forum, as of now: https://forums.aws.amazon.com/thread.jspa?threadID=291364&tstart=0 – Michael - sqlbot Oct 14 '18 at 17:57
  • I will check the system with systemtap and let you know about results – kbu Oct 15 '18 at 06:51
  • All requests to libcurl.so from amavis – kbu Oct 16 '18 at 14:49