SID 28127 System Infected Ghostnet Backdoor Activity 4

[Migration User]

We need some assistance on an alert we received last night from Network Threat Protection and Compliance.  It was for TCP Outbound to a remote host 61.216.2.13 (China).  Event description reads: [SID: 28127] System Infected: Ghostnet Backdoor Activity 4 attack blocked. Traffic has been blocked for this application: SYSTEM

Our concern is that we get this alert but no other details.  I found it in the intrusion protection logs but no alerts in antivirus about files found or quarantined.  I ran deep scans with Symantec and Malwarebytes without success (no viruses or malware found).  I can not see what specifically caused the alert to determine if a real threat.  I modified the firewall to put in a permanent block of outbound traffic to that IP address.  Thus far no more activity.

I am in the process of researching Ghostnet to see if there is a removal tool or detailed description for manual review/removal.

Hoping someone on the forums may be familiar and can provide a little more insight on how Symantec flagged this and how to follow-up on the threat using their tool.  Or, if there is another tool I should look at to ensure our server is safe.  Please advise.

Thx,

Douglas

[ℬrίαη]

Same thread here:

https://www-secure.symantec.com/connect/forums/traffic-blocked-application-system

I started seeing this yesterday. Haven't opened a case yet but it may be time to.

That external IP is the exact one I saw as well....

[Migration User]

I did a keyword search before I posted and it did not return any results. I looked for Ghostnet. Strange.

Thanks. Will try to find and run the Threat Assessment as recommended.

[Migration User]

OK - Found tool and I ran it.  It gave a warning about me running windows 2003 is not supported but the scan ran ok.

It found two errors:

Client to Manager communications are not working.  It was a host name to IP DNS Resolution.  My short hostname resolved fine. The fully qualified name did not.  I will fix.  There were two ! items listed. The first was Client is Managed.  The second is "The 'globaluseroffline; registry value in 'hkey_users\.Default\software\microsoft\windows\currentversion\internet settings' was not found". Not sure if I need to do anything about these.

One or more Symantec Endpoint Protection defination sets are corrupted. SEP 12.1.5000+ SMR definitions are corrupt. None of the products are using the latest installed definition of 20151028.036. SMR 20150303.020

Reviewing check here for solution now but don't think either error caused above. Do you?

[ℬrίαη]

What were the exact defs that are corrupt?

[Migration User]

Definition Set Name SMR

Revision 20150303.020

[Migration User]

We saw the same attack from the same IP last night.  We are running scans.

[ℬrίαη]

I have a case open on this.

[ℬrίαη]

Has anyone opened a case on this and by chance do you have an FTP service running on the affected machine(s)? Also, are your affected machines external facing?

[Migration User]

I just wanted to add I am seeing the same alert, same IP with no results from scanning using the AV or the Threat Assessment tool.

David

 

[ℬrίαη]

Is the affected machine external facing and running an FTP service?

[Migration User]

The affected machine is an Excahnge server. OWA is exposed to the internet (port 443).

No FTP servie is running on the server.

 

 

[ℬrίαη]

I'm seeing this over 443 as well

On the phone now with support

[Migration User]

It is our web server and externally facing.

We do not have FTP enabled.  All traffic is happening on 80 and 443.

Been doing a lot of reading the last 12 hrs  or so.  Not sure I fully inderstand but here is the basics on Ghost:

Somehow outside initiates the server to attempt a communication out.  I have not found an article to explains this in detail.  If the server manages to connect successfully, it will start the process of uploading files to our server and infect it.  Since Symantec managed to block the outbound traffic, I think that ended the attack without infection.  If it successfuly communicated, then we would all be dealing with a big old can of worms and our scans would find something.

There is a part of me that wants to thank SEPM but alos curse it for not relaing more information to let me know we might be safe.

[ℬrίαη]

Can you link the article?

[Migration User]

https://answers.yahoo.com/question/index?qid=20110707173502AAk5cGq

http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-detecting-apt-activity-with-network-traffic-analysis.pdf  - Page 3

http://www.techrepublic.com/blog/it-security/ghostnet-why-its-a-big-deal/

 

These were the main ones.  I followed links and read comments from these and started down the rabbit hole.  Some flat out state a user downloaded something but others offer phase 1 somehow occurs to start stage 2 which infects.  Leads me to think we all faced stage one which did not allow phase 2.

[ℬrίαη]

Thanks, I was reading the last one earlier after a search.

I have a case open but I doubt it will go anywhere since the attempt already happened and SEP blocked it. Haven't seen anything since.

[Migration User]

Been monitoring traffic since last night and I'm not seeing any more as well.

Just really want to know how the outbound traffic was initiated but glad Symantec stopped it.

[Mick2009]

Hi AKSM-IT,

Please do ensure that you check thoroughly for threats.  The IPS signature corresponds to:

Backdoor.Ghostnet
https://www.symantec.com/security_response/writeup.jsp?docid=2009-033015-5616-99

Ghostnet Toolset—Back Door at the Click of a Button
https://www-secure.symantec.com/connect/blogs/ghostnet-toolset-back-door-click-button

There may be undetected malware which has injected itself into a legitimate process and is attempting to communicate with that remote IP.

Please do keep this thread up-to-date with your progress!

With thanks and best regards,

Mick

[Migration User]

Mick,

I have thoroughly scanned the server. I am not finding any malware or virus's.

I saw and read those documents.  I did not see the files mentioned or registry entries.  I think those assume the first communication is successful and the second communication infects.

I have updated SEP client and defintions. Again, nothing found.

Tried Malwarebytes - nothing

Tried an online scan - nothing

I reviewed all IIS logs - Don't see any activity that could cause the event like post commands using forms with injection or abnormal file uploads to the server.  Symantec traffic and packet logs cleared so i don't have them to review.  The default log size was too small.  My Symantec/Veritas Backup Exec did not backup the logs.  Appears backup exec skipped the whole area - maybe by design to not interfer with antivirus operation.

Been monitoring traffic and not seeing anything unusual.

My questions are still:

1) What happened to initiate the outbound communication?  Somehow someone initiated a command that was not trapped or considered a potential threat by any of the security software.  What could initiate outbound communication on a web server that someone on the outside invokes?  I think we all just got lucky the outbound communication got stopped.

2) Since we do not do anything with countries like China and Russia, is there a way to block communication in the SEP firewall by Country?  I don't have a problem blocking all inbound and outbound traffic them.

Ideas?

[Migration User]

I had the same results as you. No registry entries or randomly named services.

I echo your concerns with question number one. That baffles me.

[ℬrίαη]

This is a handy tool:

https://www.countryipblocks.net/country_selection.php

I think Mick assuming the box had already been compromised, but, like everyone else here and on the other thread, I can find no indicators of that being the case.

[Tagin]

We also received the same events on two our internet-facing servers (one is Exchange 2010, other is Remote Desktop Gateway). No other events on those servers or other systems.

1) Blocking that IP now.

2) Running scans on those servers now. 

 

UPDATE:

-Symdiag found some Exchange DLL files it was suspicious of, but appeared to be all false positives.

-Checked registry for entries stated in Ghostnet removal page - no malicious entries found:

https://www.symantec.com/security_response/writeup.jsp?docid=2009-033015-5616-99&tabid=3

 

Original alerts in SEPM:

Risk Detected
Event Time: 04/14/2016 09:03:07 
Begin Time: 04/14/2016 09:02:05 
End Time: 04/14/2016 09:02:05 
Occurrence: 1 
Signature Name: System Infected: Ghostnet Backdoor Activity 4 
Signature ID: 28127 
Signature Sub ID: 68486 
Intrusion URL: N/A 
Intrusion Payload URL: N/A 
Event Description: [SID: 28127] System Infected: Ghostnet Backdoor Activity 4 attack blocked. Traffic has been blocked for this application: SYSTEM 
Event Type: Intrusion Prevention 
Hack Type: 0 
Severity: Critical 
Application Name: SYSTEM 
Network Protocol: TCP 
Traffic Direction: Outbound 
Remote IP: 61.216.2.13 
Remote MAC: N/A 
Remote Host Name: N/A 
Alert: 1 
Local Port: 443 
Remote Port: 29334 

Risk Detected
Event Time: 04/14/2016 09:02:11 
Begin Time: 04/14/2016 09:02:12 
End Time: 04/14/2016 09:02:12 
Occurrence: 1 
Signature Name: System Infected: Ghostnet Backdoor Activity 4 
Signature ID: 28127 
Signature Sub ID: 68486 
Intrusion URL: N/A 
Intrusion Payload URL: N/A 
Event Description: [SID: 28127] System Infected: Ghostnet Backdoor Activity 4 attack blocked. Traffic has been blocked for this application: SYSTEM 
Event Type: Intrusion Prevention 
Hack Type: 0 
Severity: Critical 
Application Name: SYSTEM 
Network Protocol: TCP 
Traffic Direction: Outbound 
Remote IP: 61.216.2.13 
Remote MAC: N/A 
Remote Host Name: N/A 
Alert: 1 
Local Port: 443 
Remote Port: 29334 

 

[Migration User]

That is a nice link - Thanks.

[Torb]

Seen the same. A front end Lync server. Has anyone recieved details from Symantec on how this signature works? It might just be a an external site that performs scans against our networks and SEP drops it because of a known bad ip adresse. Since everyone is seeing the same IP :61.216.2.13

 

Torb

[ℬrίαη]

I have a case open. I'll provide further details some time today.

[JASON LINDSEY]

Thought I would mention I just noticed this threat yesterday on my SBS 2011/Exchange server.  Outbound to 61.216.2.13 port 443, which is open for Exchange/OWA.  I am in the process of running scans but so far I have found nothing else to indicate an active threat so I am a little baffled as to what really caused this. 

[Migration User]

Does anyone have an update on this?  We also received a warning and have been unable to detect anything wrong with the affected server.

[Migration User]

Jason84, Welcome to the group of "Baffled".

You may have an opportunity that I did not.  Look in your traffic/packet logs and make a backup of them.  Mine cleared out before I could look at them in detail.  Wanted to review all traffic just before the event to see who all was communication with my server.  May find a clue there.

SEP by default had my logs at 512K.  Due to the amount of activity on my server, my logs only maintained like 4hrs of activity.

[ℬrίαη]

Not much to update and in the same boat here as everyone else.

I have logs in my gateway firewall to indicate 61.216.2.13 as the source attempting to scan our external IPs. SEP IPS obviously blocked it so there was nothing going back. I still feel this was initiated from 61.216.2.13 (and is a false positive as the system is not truly infected IMO) but without seeing how the IPS rule is written, I don't have a solid answer.

[JASON LINDSEY]

I will take a look at these shortly and report back, thank you for the suggestion. 

Is there a way to enable better notifications of IPS intrusions like this?  I can't seem to find a way to enable an email or user notification for detections within IPS.  I was simply combing through the Event Viewer logs when I noticed one for Symantec IPS related to this event.  Had I not been looking at logs this morning I may have missed it entirely unfortunately. 
 

[Tagin]

You can create an email alert in SEPM.

Monitors > Notifications > Notification Conditions (button)

From that screen you can add/edit/remove notifications.

Add > Client Security alert

On the form that comes up:

• Name the notification
• Check the Network Threat Protection Event box
• Check Send email to and enter an email address

 

[WHairstonLOI]

One of our clients experienced this last night as well - same outgoing TCP attempt to 61.216.2.13:29334 was blocked. Windows Server 2008 R2 with a public-facing Exchange OWA on TCP port 443 (which was indicated as the "Local" address/port in the SEP Client Management Logs - Security Log).

From what I gather reading/researching, it sounds like an external hacker attempt initiated the attack, with SEP blocking the response, but I'm getting ready to run an assortment of malware scans "just in case."

Hoping to hear some more detailed info on this post soon regarding what actually happened.

[Migration User]

We noticed an 'attack' the same as this at 3am this morning, we've pushed this over to our hosting and infratructure team after investigating ourselves and they have come up with nothing at all. We're currently running a full system scan over the weekend.

In my opinion, this is a false alarm, however i'm not the expert here and that's why I put my trust in the SEP product!

Strange though as so many users here have the same IP, same denial in SEP and so answers.......

[ℬrίαη]

I wouldn't expect a response from Symantec. While the 'System Infected' identifier is incorrect IMO, IPS did stop a malicious attempt so it did its job in that sense.

From all I can see and have researched, this was initiated externally.

[pbolduc]

This is definitely not an infection on the host. I am experiencing the same problem as of 1 hr ago I was notified through an e-mail alert of:

IPS Alert Name
Attack: an intrusion attempt was blocked.

Status
Blocked

Attack Signature
System Infected: Ghostnet Backdoor Activity 4

My server is a Microsoft Windows 2008 R2 server being used as a Terminal Server with No Internet for the clients. The ports open on this server are 443 which the users connect through IIS to RDWEB to access their RDP Desktop. This event does concern me, but when I check the History in the Symantec Console I see no log of this error nor do I see where this problem originated from.

My Symantec Endpoint Protection defs are: 12.1.4013.4013

Symantec.Cloud Endpoint Protection SEP-12.1.4013.4013

Symantec.cloud - Cloud Agent: 2.03.71.26.18

If anyone is able to get to the bottom of this attack I would be interested in knowing a bit more information on this.

 

Much appreciated,

Paul

[Migration User]

I have also seen these intrusion signatures of the last few days. So far the event has occured on three different public facing Windows Servers (All of which are running Server 2012 r2). Each time the event was an outbound TCP connection on port 443 to 61.216.2.13

I have done some digging through our IIS logs and cannot see any traffic to or from this address, however our firewall logs (across multiple sites) show various probes from this IP Address (61.216.2.13) trying to connect to various web servers on port 443 over the last 30 days.

I have opened a ticket with Symantec, although they have requested packet capture from the servers in question which I am unable to provide, as the event is not repdoceable on demand.

I have blocked all traffic to and from this IP address on our perimeter firewalls and will continue to log at that level to see if the event is being triggered from this address externally.

I will post again here if I find out anything note-worthy.

[Migration User]

After blocking all inbound traffic from 61.216.2.13 at my perimeter firewalls, I am no longer seeing any of these outbound TCP intrusion events being triggered from Symantec EPP.

I am now fairly confident that these outbound intrusion events are false positives being tirggered by an inbound intrusion attempt from 61.216.2.13, but I cannot be absolutely sure.

My firewall logs show this IP address scanning my entire public IPv4 space (across multiple sites) on the following ports: 80, 443, 8080, 8089, and 666. This bad host is most likely scanning the entire global IPv4 public space.

[Migration User]

Just an update from my end.

No closer to figuring out how the attack started.

Blocking the specific IP at external firewall and soft firewalls.  No additional alerts.

I am thinking Brian is correct. We are not going to get anything more from Symantec on this.  SEP blocked the second half of the attack and kept us safe.  Won't help me sleep much at night knowing there is a potential hole that let them initiate that outboud traffic.

I'm marking as closed for now and giving Brian credit for trying to take it to the next level.

Good luck all - Hope we don't see this again.

[Warp9point9]

We had a warning message come up on our server this morning.  Symantec said they issued a updated a few days ago 4/17/2016 that addresses this issue.  I had a tech check our system remotely and it's ok.  

https://www.symantec.com/security_response/writeup.jsp?docid=2009-033015-5616-99

this is what the send me to read. But i've scanned our system 2 to 3 times.  

[Migration User]

Response from Symantec regarding my case for this issue:

 

IPS signature IPS SID 28127 "System Infected: Ghostnet Backdoor Activity 4" was toggled to silent since last Friday after a large uptick in detection rate.
The IPS team investigated deeper and since Monday the signature has been tightened and based on tightened signature only a small amount of ping coming from ip61.216.2[.]13

 

Otherwise, the signature has been tightened and released to blocking again, so you may not find issue with current block signature since tightening.