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?

  • 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 '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
  • 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

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

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