Monday, March 9, 2015

Critical Infrastructures And The Energetic Bear ... Big Picture Implications



Who are they?
Energetic Bear is an Advanced Persistent Threat (APT) group whose targets lie mostly within the energy sector. In addition to targeting the energy sector, they have also targeted organizations in other verticals such as Aviation and Defense. The countries targeted by this group were US, Canada, Spain, France, Italy, Germany, Turkey and Poland. Their attacks are carried out via methods such as spear phishing, watering hole, remote access tools and trojanized software (Symantec, 2014). While some researchers state the group operates in Eastern Europe (Symantec, 2014), others have been more confident and specific, suggesting that this threat actor is directly connected to the Russian Government. It is believed that the objective of the Russian Government is to promote Russia’s national economic interest along with helping its industries to maintain competiveness in key areas of national importance (Finkle, 2014).

The Big Picture Implication
Groups like Energetic Bear poses a clear and present threat to our Critical Infrastructures and hence our National Security. By successfully penetrating organizations within our Energy Sector this group may be in a position to control the amount of heat we get in our homes during the winter, blow up a nuclear energy facility or even flood a hydro dam. While the primary impact may be physical destruction, the secondary and other consequential damages can be devastating. For any of the above, there can be significant loss of life, significant economic loss and or mass hysteria. Communications systems can be affected thus affecting emergency services personnel from being able to successfully perform their duties. The Energy Sector is basically the engine that drives the other 15 Critical Infrastructure Sectors and any threat that reduces its effectiveness and or the quality of its output, immediately affects the input to the 15 other critical infrastructure sectors. A 30-minute power outage is said to cost business around US$15,709. For shorter blackouts which occurs several times a year in the United States (US) it is reported than this results has an annual economic loss of between US$104 and US$164 billion (agcs.allianz.com, n.d.).  The significant of these numbers show that for any situation of which the real owners and operators of these infrastructures do not have full control of their systems, the outcomes of someone malicious gaining control cannot be over stated.

What should be done about this group?
The ultimate objective when dealing with groups like Energetic Bear would be to work with the Governments and owners of Critical Infrastructures along with the rest of the security community, combining efforts towards dismantling the group or the creation of initiatives which may reduce its effectiveness. However, one should be aware that it can be very difficult to attribute attacks in cyber space (Schneier, 2015).  As can be seen above, Symantec suggested that the group operates out of Eastern Europe (giving Symantec a broad territory) while CrowdStrike was more specific claiming it was the Russian government.  
While dismantling the group would be very nice to achieve, the reality is we need to make greater effort at securing our systems and critical infrastructures.  The vulnerabilities exploited by Energetic Bear (CVE-2013-2465, CVE-2013-1347, and CVE-2012-1723 in Java 6, Java 7, IE 7 and IE 8) (kasperskycontenthub.com)were already known and should have been patched.  If for business reasons these devices were or are unable to be patched, all efforts should be made to ensure the relevant technical and or administrative controls are in place to mitigate any attacks destined for these hosts. However, since Energetic Bear exploits Internet Explorer (IE) and Java, these being known client side applications, I will conclude that business reasons may not have been the primary reason why these devices were on patched.  
Some of the technical controls which may work in these situations are reducing and or eliminating the use of administrative credentials, implementation of Intrusion Prevention Systems (IPS) which should block this communication from being successful and or Security Information Event Management (SIEM) solutions which can help to store logs, correlate data and alert on potential threats if they were successful. While these solutions may not prevent these attacks, it does help an organization to understand the scale of the attack if and or when it is has been successfully targeted and compromise, while also reducing its attack surface.

Conclusion
Attribution in cyber space is very difficult, this makes justified retaliation extremely hard. Similarly defense is harder than offence, thus we need to ensure we are recording as much relevant information as possible and where possible. From a big picture perspective, these groups pose a clear and present threat to Critical Infrastructures and hence National Security. Containing APT Threat Actors like Energetic Bear may be difficult, thus protecting our infrastructure and systems through either prevention or detection solutions should be paramount.

References

(n.d.). Retrieved from kasperskycontenthub.com: https://kasperskycontenthub.com/securelist/files/2014/07/EB-YetiJuly2014-Public.pdf
(n.d.). Retrieved from agcs.allianz.com: http://www.agcs.allianz.com/insights/expert-risk-articles/energy-risks/
Finkle, J. (2014, January 22). Retrieved from reuters.com: http://www.reuters.com/article/2014/01/22/us-russia-cyberespionage-idUSBREA0L07Q20140122
Schneier, B. (2015, January 8). Retrieved from schneier.com: https://www.schneier.com/blog/archives/2015/01/attack_attribut.html
Symantec. (2014, June 30). Retrieved from symantec.com: http://www.symantec.com/connect/blogs/emerging-threat-dragonfly-energetic-bear-apt-group

Saturday, March 7, 2015

Tuning Snort - detection_filter with event_filter


Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.

In this post we will combine detection_filter with event_filter.
It is important to note that event_filter is the recommended method of thresholding.

This lab consists of the following:
    Windows 2003 - Telnet Server - IP: 10.0.0.2003
    Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1


For this we will start off with a rule that is only configured for detection_filter. If you missed the previous post on using detection_filter, you can click here to get that info and then come back to this one.


This rule looks for greater than 6 alerts before it starts to fire. Basically, if we do 10 failed logons, it will ignore the first 6 then alert on everything else thereafter.

Let's test that
Let's perform our failed logon












So our logon failed ...  let's see what snort sees


Looks like we got 4 alerts.


Let's verify the performance data


Looks good. There were 10 checks, However only 4 were matched and 4 alerts were generated.

Now if we had 100 or more alerts generated after the first 6, this would have been a very noisy deployment. One which would make any Intrusion Analyst cringe.

To reduce this noise let's add the event_filter option.
Remember, event_filter replaces threshold, so to configure this we modify the threshold.conf file which is found in /etc/snort/

Below shows the entry which was echo'd into thresholds.conf file. If you need guidance on on how the threshold command is used click here.


Running snort again and the failed logins we see ....


As seen above, snort generated 1 alert.

Let's see what the performance data shows


...a thing of beauty. So we had 10 packets which were checked. From that 4 matched. However, we only generated 1 alert.



Hope you enjoyed this post. See
threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.


References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx

Tuning Snort - Detection_filter

Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.
In this post we will look at tuning via detection_filters in Snort Version 2.9.2.2.

This lab consists of the following:
    Windows 2003 - Telnet Server - IP: 10.0.0.2
    Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1


According to manual.snort.org "detection_filter defines a rate which must be exceeded by a source or destination host before a rule can generate an event". For this we will try to do 10 failed logins within 60 seconds.


As always let's see what the rule looks like. This rule is a basic rule without the detection filter. The idea is to see how the rule operates before we add the detection filter.


Now let's produce our failed logon











Looks good.

Let's see what snort generated



Looks good, we have 10 alerts.

Now let's see what the performance data shows.

Looks good again. We have 10 Checks, 10 Matches and 10 Alerts.


Let's try to reduce some of this noise

This time the rule looks for 6 matches within 60 seconds and then alerts on everything else. So if we have 10 failed logons within 60 seconds, the first 6 would be ignored and the last 4 would be alerted on.

Let's verify this.
Assume that we generated the 10 failed logons again


Looks like we got 4 alerts.

As always let validate this. Looking at the performance data we see ....

From the above we see we had 10 Checks. However, there were only 4 matches and thus 4 alerts.

The above produced 4 alerts, thus we should consider what would happen in the case there were actually more than 10 failed logons.

To address the above concern with too many messages, our last post in this series will be based on using event_filter with detection_filter.

Another important point to note is that unlike, threshold or suppress which are post detection activities, detection_filter is the last step during the detection phase and not a step done in the post detection phase.


Hope you enjoyed this post. See
threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.


References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx


Tuning Snort - Suppress

Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.

This lab consists of the following:
    Windows 2003 - Telnet Server - IP: 10.0.0.2
    Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1

In this post we will look at tuning via suppression in Snort Version 2.9.2.2.

Let's start off with our rule
The rule below is just a basic rule looking for the content "Logon failure" coming from host 10.0.0.2:23 going to host 10.0.0.1. No suppression is enabled.

Let's logon via telnet











As seen above my logon failed. Let's assume this happened 6 times.
For every failed logon received from the server there is a Snort alert above.

Looking at the performance statistics. We see 6 Checks, 6 Matches and 6 Alerts



Let's now go ahead and configure suppression.

This is done via the "threshold.conf" which is found in /etc/snort

Once configured let's go ahead and create our failed logon sessions again, similar to above.

When snort is run again, there is no output on the screen.


However, as we check the performance data we see we have Checks 6, Matches 6 and Alerts 0.


What this confirms is that even though we suppress this alert, snort is still processing the packeet. However, no notification is provided to us as to what is going on with the packet.



Hope you enjoyed this post. See
threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.


References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx

Tuning Snort - Thresholding

Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.

In this post we will look at tuning via thresholding.
Before we move forward, I must state that the snort documentation states this is a deprecated function and will not be available in future releases. These posts are being used with snort Version 2.9.2.2. Threshold has been replaced with event_filter.

Using the snort documentation as a guide, one of the examples it has is detecting 5 failed logons using the "limit" option. Threshold itself has a few options to be aware of. These are threshold, limit or both. In this post we will look at all 3.

This lab consists of the following:
    Windows 2003 - Telnet Server - IP: 10.0.0.2
    Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
   

Let's get started
Let's create rule which looks for failed logons via telnet without any thresholding.
Below shows the snort rule which is looking for the failed logons. It currently has no threshold configurations


From below we see the failed logon. For this I actually did this 5 times, however there is no need to put all of this in the image. Just consider this as 5 failed logons.











The snort rule fired 5 times as can be seen below

When we look at the performance statistics, we verified that this rule was checked 5 times, matched 5 times and alerted 5 times.


Let's now add the threshold option "limit" to the rule and see the results.
Basically, for the limit, it does not matter how many telnet packets are seen between the hosts with "Logon failure" within 60 seconds, it will simply fire on the first 2 and ignore everything else. To actually test and understand this, you should be running snort in one window which is visible and logon to telnet via another window which allows you to see the snort screen while you are logging in. What you should see is snort generating an alert on your first login, then on your second login. For all the others within 60 seconds there should be no results from snort.

Let's test this.


Create a new rule with limit enable


Let's assume I have 5 failed logins as similar to above.

Below we see that the snort rule triggered only 2 times. This would be the first two then everything else was ignored.


Let's see what the performance statistics show.

Above we see that similar to the first rule, there were 5 checks and 5 matches. However, in this case there were only 2 alerts.


Let's move over to the "threshold" option now
The rule below is basically the same rule which was used for "limit". However the threshold type has been changed to threshold.


What this rule will do, is for every 2 packets seen with "Logon failure" between the two hosts, it will create an alert. So basically every second failure an alert would be created.

Once again, let's test that
Let's assume I have 5 failed logons again. Remember, to truly understand this, you should be able to look at your snort window or terminal, while logging to your telnet session.

Below we see the snort rule fire again 2 times.


Let's see what the performance statistics shows


Once again we saw 5 checks, 5 matches but 2 alerts.

I know at this point you may be thinking this seems confusing as you still have 2 alerts generated. However, remember above we had 5 failed logons, so we are unable to get more than 2 snort alerts.

To make it easier I will do one more example.
This time we will use 10 failed logons while keeping the rule the same. So if, this rule looks for every 2 failed logons within 60 seconds then for 10 failed logons we should have 5 alerts.

Let's test this.
Rule below is basically the same as above


Let's see what snort throws our way after the failed logons



As can be seen this time around, snort generated 5 alerts.

As always let validate this against what the performance preprocessor sees.


Ahhhhhhhhhhh!!! A thing of beauty.


The final option for threshold is "both". Both simply alerts once per interval based on the count value.

For the rule below, snort alert would be triggered on the 2nd packet seen with "Logon failure" between the hosts and everything else is ignored within the seconds specified.


Let's see what alerts we get.


As see above the the rule fired once.

Once again, let's check the performance statistics


Looks like we had 10 checks and 10 matches. However, only 1 alert was fired. This obviously matches what we stated earlier.

One of the things we were able to achieve with this post is for every test we were able to successfully validate our findings via various means.

Hope you enjoyed this post. See
threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.


References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx

Friday, March 6, 2015

Critical Windows Processes - smss.exe, wininit.exe, services.exe, winlogon.exe, csrss.exe


Similar to the "System Idle Process" and the "System" process, smss.exe, wininit.exe, services.exe, winlogon.exe, csrss.exe are some one of the other critical processes to be aware of on Windows systems. Many times, malicious processes will have the same or similar names as legitimate processes, so it's important that we are able to differentiate between what's legit and what's not legit.

Session Manager Subsystem (smss.exe)

   





















  








   
    - Initiated by System PID 4

    - Parent should be marked as "System" with PID 4   
    - In contrast to the "System Idle Process" and the "System" processes, this actually points to a valid executable - C:\Windows\System32\smss.exe  
    - First user mode process created
    - Responsible for starting user sessions
    - Should have only 1 active copy once the system has initialized
   
      
Windows Initialization Process (wininit.exe)

































    - Gets created by smss.exe
    - However, the parent smss.exe dies leaving wininit.exe parentless
    - creates %windir%\temp
    - Creates services.exe and lsass.exe
    - Similarly to smss.exe, this process is actually pointed to a specific executable - C:\Windows\System32\wininit.exe
   

Services Control Manager (services.exe)


   






























    - created by wininit.exe
    - used for interacting with services

      - Similarly to smss.exe, this process is actually pointed to a specific executable - C:\Windows\System32\services.exe   
   

Windows Logon (winlogon.exe)
 



























  



    - created by wininit.exe
    - used for interactive logons and logoff
    - Works in conjunction with credential providers

    - Similarly to smss.exe, this process is actually pointed to a specific executable - C:\Windows\System32\winlogon.exe   

  
Client Server Runtime Subsystem (csrss.exe)





























 



    - User mode portion of win32 subsystem
    - Responsible for console windows
    - Legacy process from the days of WindowsNT
    - Responsible to drive mapping, temp files creations, etc

    - Similarly to smss.exe, this process is actually pointed to a specific executable - C:\Windows\System32\csrss.exe   
    - Non existent parent process 



Why does all of this matters? Thought you would never ask ... Being able to identify processes in general will be helpful in determining what you investigate. However, knowing what is critical and their characteristics can make your investigation process much easier.





References:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063%28v=vs.85%29.aspx
https://technet.microsoft.com/en-us/sysinternals/bb545021.aspx
https://technet.microsoft.com/en-us/sysinternals/bb963901.aspx
https://social.technet.microsoft.com/forums/windows/en-US/3dce3625-2757-43d8-9289-0f5f1f832fad/system-idle-process-and-its-existence
http://en.wikipedia.org/wiki/System_Idle_Process
http://www.tutorialspoint.com/operating_system/os_processes.htm
http://support2.microsoft.com/kb/263201
https://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx
https://sysforensics.org/2014/01/know-your-windows-processes.html