This question already has an answer here:

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?

marked as duplicate by ceejayoz, Greg Askew, kasperd, womble Oct 14 at 0:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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? - but first, shut the server off so it stops attacking people. – ceejayoz Oct 12 at 13:22
  • Sorry, but your answer can't help solve the problem and do not answer my question. Thank you. – kbu Oct 12 at 13:24
  • It may not be the answer you want to hear, but it is the answer. – ceejayoz Oct 12 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 at 13:36
  • 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 at 14:14

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.

  • 1
    "to find which process sent udp packets to dns" while remembering that DNS uses TCP as well... – Patrick Mevzek Oct 12 at 16:55

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.

  • 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 at 11:46
  • Yes, it was every 6 hours – kbu Oct 14 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: forums.aws.amazon.com/thread.jspa?threadID=291364&tstart=0 – Michael - sqlbot Oct 14 at 17:57
  • I will check the system with systemtap and let you know about results – kbu Oct 15 at 6:51
  • All requests to libcurl.so from amavis – kbu Oct 16 at 14:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.