Wednesday, September 20, 2017

Looking to expand your knowledge on Intrusion Detection or Incident Handling, Hacker Techniques and Exploits? Then come hangout at one of my upcoming classes to learn more!

Upcoming Courses Taught By Nik Alleyne
TypeCourse / LocationDateRegister

Community SANS
Community SANS Chicago SEC504* Chicago, IL
Oct 9, 2017 - 
Oct 14, 2017

Community SANS
New
Community SANS Ottawa SEC503 Ottawa, ON
Oct 16, 2017 - 
Oct 21, 2017

Community SANS
Community SANS Des Moines SEC504* Des Moines, IA
Oct 30, 2017 - 
Nov 4, 2017

Community SANS
Community SANS Toronto SEC504 Toronto, ON
Nov 13, 2017 - 
Nov 18, 2017

Community SANS
New
Community SANS Pensacola SEC503 Pensacola, FL
Nov 27, 2017 - 
Dec 2, 2017
*Course contents may vary depending upon location, see specific event description for details.

Learning about malware persistence through the lens of IMWorm leveraging “Autoruns”

In this series of posts, I’m continuing the Open Security Training materials, with this set of post being more focused on the Malware Analysis class.

You may find reviewing the material from Open Security more beneficial. However, if you do choose to stick with this I hope you find it helpful.

In this post, we will be learning about the persistence mechanism used by IMWorm. We will leverage Sysinterals Autoruns to expand our understanding of IMWorm’s persistence.

To make this analysis a bit easier, I first executed Autoruns and saved the output via the “File” -> “Save” menu to a file called “Before_IMWorm.arn”.

Once I had the saved file, I then executed the IMWorm executable and compared the new Autoruns output to this saved file. To achieve this, I first hit “Refresh”/”F5” within Autoruns. Then from the “File” -> “Compare” menu item, I selected the file “Before_IMWorm.arn” which was previously created. Once opened, this produced the output shown below:

As shown above, the registry entry ‘"HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" /V UserInit’ has the value of “C:\WINDOWS\system\lsass.exe”. Additionally we see the file “msconfig.exe” has been created in the "c:\Documents and Settings\All Users\Start Menu\Programs\Startup".


Let’s try to hunt these down:
First when I tried to open “regedit” to verify the key, I was unable to do so and I believe this has something to do with “IMWorm”. The error I got was “Registry editing has been disabled by your administrator” as shown below:



As a result of this error, I instead leverage the “reg query” command line tool. This produced the result as follows


The example above demonstrates why it is extremely important to know and use more than one tools to solve your problems.

Next up I attempted to leverage Autoruns to “Jump to Image”. However, Autoruns exited and I was unable to open it. Looking for the file directly under Windows Explorer, I was also unable to find it. Trying to enable the option to show hidden files and file extension, I noticed those options were not available. I assumed once again, this is IMWorm doing its thing.

As a result, I had to go back into the command line with some more command line Kung Fu. At this point I did a “dir” on the folder in question as shown below:


Ooooops!! Loos like nothing is there. Let’s take another shot at this looking for hidden files. This time we execute the same command except we append “/A H” to the output above as shown below:
 
At this point we recognize the file was “hidden” from the default “dir” output.

From above, we see that IMWorm is leveraging both the registry “Run” key and the “Startup” folders for persistence purposes.






Wednesday, September 13, 2017

I Smell A RAT – Learning about Poison Ivy – Live Forensic Analysis

In this series of posts, I’m continuing the Open Security Training materials with this set of post being more focused on the Malware Analysis class.

You may find reviewing the material from Open Security more beneficial. However, if you do choose to stick with this I hope you find it helpful.

In this post we will take a quick pass at some live forensic analysis. See the reference section for some other analysis you may undertake.

First up, I’ll start off with the network through leveraging “netstat” on the “compromised” host. The network information below shows that the host “Securitynik-xp” on source port 1025 has an established connection to host 10.10.10.1 on port 3460.

Now that we have an established connection, let’s see what is the PID and owning process of this connection. Leveraging the “neststat –ob” as shown below.

 
Above we see the owning process is “system32:secnik_piv.exe” and it has a PID of 1688.

By looking at the “:” in “system32:secnik_piv.exe” we can conclude that this is more than likely an Alternate Data Stream (ADS).

Doing a “dir c:\windows\system32\secnik*.exe” we see … basically the file was not found. In Windows XP there is no immediate way to detect ADS without third party tools.

Therefore let’s leverage Sysinternals “Streams.exe” to identify the ADS in “system32”. The image below shows that “secnik_priv.exe” is embedded in “c:\windows\system32”
Taking a look at the registry for persistence, we see the key "HKLM\software\Microsoft\windows\CurrentVersion\Run" has a value “SecurityNik_PIvy_Agent      REG_SZ  C:\WINDOWS\system32:secnik_piv.exe”
 

Taking a look at ProcessHacker to learn more about the process “system32:secnik_piv.exe”, we see that it was started by “explorer.exe”. We also see that this process has spawned a “cmd.exe” process. If we remember from this post, we were interacting with the “compromised host” via the command shell.
At this point, we can continue to leverage ProcessHacker or even identify additional tools which can assist with our live analysis.

However, we were able to identify it’s persistence mechanism which allows it to survive reboot. At this point we can take the next step which is to begin the clean-up process.

Let’s start with deleting the persistence mechanism via the registry using “reg delete "HKLM\software\Microsoft\windows\CurrentVersion\Run" /v "SecurityNik_PIvy_Agent"”
We see from the final entry above that "SecurityNik_PIvy_Agent” has been deleted.

Let’s now look at suspending the process “system32:secnik_piv.exe” before we attempt to delete it from the ADS.

Leveraging ProcessHacker once again we first suspend the process … 

… once suspended we then leverage GMER to delete the file as shown below …
If we take a look at “c:\windows\system32:secnik_priv.exe” with Sysinternals “streams.exe” we see the file no longer exists as show below.

Now let’s close this off by terminating the process tree for “system:secnik_priv.exe


At this point, consideration should be given to the fact that the process may be recreated, therefore close attention should be paid to monitoring. Additionally, you may want to monitor the network for traffic known to be associated with Poison Ivy. Restarting the “infected” system is a good way to verify that all is well.


Monday, September 4, 2017

I Smell A RAT – Learning about Poison Ivy – The Capabilities

In this series of posts, I’m continuing the Open Security Training materials with this set of post being more focused on the Malware Analysis class.

You may find reviewing the material from Open Security more beneficial. However, if you do choose to stick with this I hope you find it helpful.

In the previous post we looked at the setup of Poison Ivy. In this post we will look at some of its usages.First up, let’s look at the “Information” menu on the left. This produces 

 

Next up, leveraging the “Files” menu, a list of files which are on the “compromised” system.


The “Registry” menu item shows the “compromised” host’s registry. This can also be interacted with.
 

The “Process” menu allows for viewing and interaction of the processes currently running on the host.
 


Similarly, the “compromised” client’s “Services”, “Devices”, “Installed Applications”, “NT/NTLM Hashes”, can be seen.

Below the “Active Ports” shows current “netstat” information.
 

The “Remote shell” option allows interaction with the “compromised” host’s shell. You first need to right click and choose “activate”. The image below shows interaction with the host’s shell.

 
Below screen shows the “NT/NTLM hashes” retrieved from the host.


As can be seen in the “Administration” section, there are options to “Edit”, “Share”, “Update”, “Restart” and even “Uninstall” the malicious binary.




Tuesday, August 29, 2017

I Smell A RAT – Learning about Poison Ivy – The Setup

In this series of posts, I’m continuing the Open Security Training materials, with this set of post being more focused on the Malware Analysis class.

You may find reviewing the material from Open Security more beneficial. However, if you do choose to stick with this I hope you find it helpful.

In this post, we will be learning more about setup and configuring Poison Ivy. In the next post we will look at learning about its capabilities while in the final post, we will try to analyze and learn more about detecting it.

My lab consists of 2 virtual machines. A Linux virtual machine which will be my command and control (C2) server/Poison Ivy client and a WindowsXP machine which will be the Poison Ivy Sever.On loading up the Poison Ivy executable in Linux we get the EULA screen:














Once we acknowledge the EULA, the next screen is the home screen:


From here we next select the “File” menu and select “New Server”. This is the executable which will be “sent” to the client and when it is executed, it will connect back to our C2 server or from Poison Ivy perspective, our “Client”.


Next up is to focus on the connection information:

From above, I’ve added multiple C2 Servers IPs as well as some domain information. The list consists of:
10.10.10.1:3460:0,
10.0.0.103:3460:0,
192.168.0.1:3460:0,
172.16.23.5:3460:0,
securitynik.web:3460:0,
ivy.securitynik.web:3460:0,
malware.securitynik.wejb:3460:0,


Once the C2 servers have been added, click “Next” at the bottom right which now produces the “Install” screen. In my example below I’ve set the persistence mechanism through HKLM/Run Name” as “SecurityNik_PIvy_Agent”. I’ve also enabled the “Copy File” and provided it with filename “secnik_piv.exe”. This will copy the file to the “system” folder and will also leverage Alternate Date Streams  through “Copy file to Alternate Data Streams”.


Once the above is completed, click “Next” at the bottom right of the above screen. This then brings up the “Advanced” window. I did not modify anything in this window so click “Next” which then brings up the “Build” screen.

In the “Build” screen, I choose generate to generate the new binary which brings up the window to save the file as shown below:

Once the above file is saved, click “OK”.

Now that the file has been generated, I’ve leverage Python’s Simple HTTP Server to serve the file to the client.

From below, we see Python’s Simple HTTP Server serving up the file

securitynik@siftworkstation:~/MalwareClass/PoisonIvy-2$ python -m SimpleHTTPServer 8000
Serving HTTP on 0.0.0.0 port 8000 ...
10.0.0.101 - - [03/Aug/2017 17:56:01] "GET / HTTP/1.1" 200 -
10.0.0.101 - - [03/Aug/2017 17:56:07] "GET /SecurityNik_PoisonIvy.exe HTTP/1.1" 200 -
Now that the setup for the Poison Ivy server is complete and the file has been “delivered” to the client, it’s now time to setup the Poison Ivy Client.

From Poison Ivy’s “File” menu, select “New Client”. This brings up the screen below.

In the above example, I left everything at their defaults, then choose “start”. This now brings up the screen below which shows Poison Ivy waiting for connections.


At this point the setup is completed.

Let’s do one more thing before we go to the next post and that is to execute “SecurityNik_PoisonIvy.exe” on the Poison Ivy Server. Once executed successfully, this then produces the following.















As shown above, our client at “10.0.0.101” has successfully registered.

See you in the next post where we look at learning more about Poison Ivy’s capabilities.


Python Simple HTTP Server


Other posts in this series:

I smell a RAT – Learning about Poison Ivy – Live Forensics Analysis

Monday, August 21, 2017

Still Splunking Parsing TinyProxy logs – Building a monitoring system on the cheap

Having a proxy in your infrastructure, is essential for many different reasons. The first two to come to mind is bandwidth management and from a security perspective it gives excellent visibility into the domains and URLs being accessed by resources on your network. 

In this post, we will continue our building a monitoring system on the cheap by leveraging Splunk (free version) to identify domains and URLs which are detected, refused and allowed on our infrastructure via the TinyProxy proxy server.

Let’s get going!

First up with Splunk, let’s identify the log source so that we can focus on this traffic. In my case Tinyproxy has “source = /var/log/tinyproxy/tinyproxy.log” and “sourcetype = Tinyproxy”. Using either or both of these we can focus our search and filters.

Let’s filter our TinyProxy event types using “* sourcetype=Tinyproxy | rex field=_raw "(?<event_type>.*?\s+)" | stats count by event_type | sort count | reverse

This produces the following:

Now that we have the different event types, let’ save this and then focus on each of these to build our dashboard out.

Let’s first look at the hosts connecting to our proxy. This can be achieved through the use of the following search “* sourcetype=Tinyproxy CONNECT | rex field=_raw ".*\[(?<requesting_host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$" | stats count by requesting_host | sort count | reverse

The above search produced:






















Next up let’s look at the HTTP methods which are being seen. The search “* sourcetype=Tinyproxy CONNECT | rex field=_raw ".*\):\s+(?<http_method>[A-Z]*?\s+)" | stats count by http_method | sort count | reverse” helps us to gather this information as seen below.














Next up let’s identify the URLs which are being requested via GET or POST methods using the search “
* sourcetype=Tinyproxy CONNECT | rex field=_raw ".*\):\s+(?<http_method>(GET|POST)*?\s+)(?<url>.*?)HTTP" | stats count by url | sort count | reverse” we get the following:

Next up let’s identify the domains which are being allowed by leveraging the search “* sourcetype=Tinyproxy CONNECT established | rex field=_raw "Established\s+connection\s+to\s+host\s+\"(?<allowed_domains>.*?)\"\s+" | stats count by allowed_domains | sort count | reverse”. This produces the following

Now that we have the URLs as well as the domains being requested, let’s now figure out the domains and URLs which are being rejected.
First let’s look at the domains using “* sourcetype=Tinyproxy NOTICE | rex field=_raw ".*filtered\s+url\s+\"(?<filtered_url>(http|https).*?)\"" | stats count by filtered_url | sort count | reverse

This produces:
 
Focusing in specifically on the domains using the search “* sourcetype=Tinyproxy NOTICE | rex field=_raw ".*filtered\s+url\s+\"(?<filtered_domains>.*:(80|443)?)\"" | stats count by filtered_domains | sort count | reverse” we get

 
So that’s it for this post. Hope this helped you to make better use of your Splunk Dashboard skillz.

Reference: