Saturday, December 13, 2014

Building snort 3.0 (snort++)

Now that snort has released snort++ (snort3.0) I've decided to publish a how to for Kali (fresh install)

root@securitynik:~# lsb_release -a








Install libgmp-dev libmpfr-dev libmpc-dev






Instead of installing the above, you could have also download the pre-requisite via:
root@securitynik:~/downloads/gcc-4.9.2# contrib/download_prerequisites
However, to use the above, you need to ensure you allow ftp through your firewall.


INSTALL GCCwget http://gcc.skazkaforyou.com/releases/gcc-4.9.2/gcc-4.9.2.tar.gz
    tar -xvf gcc-4.9.2.tar.gz
    cd gcc-4.9.2
    ./configure --prefix=/usr
    make && make install   


INSTALLING LIBPCAP
next we download, extract and build the latest "libpcap"
    wget http://www.tcpdump.org/release/libpcap-1.6.2.tar.gz
    tar -zxvf libpcap-1.6.2.tar.gz
    ./configure --prefix=/usr
    make && make install


INSTALL DAQ

    tar -zxvf daq-2.0.4.tar.gz
    cd daq-2.0.4
    ./configure --prefix=/usr
    make && make install
   

INSTALLING LIBDNET

continuing the install, next we obtain and install "libdnet-1.12 source .tgz"
root@securitynik:~/downloads# wget https://libdnet.googlecode.com/files/libdnet-1.12.tgz
    tar -zxvf libdnet-1.12.tgz
    cd libdnet-1.12/
    ./configure --prefix=/usr
    make && make install
   
   
INSTALLING LuaJIT-2.0.3

Once gcc has been successfully installed, next step was to install "LuaJIT-2.0.3"
    git clone http://luajit.org/git/luajit-2.0.git
    cd luajit-2.0/
    make && make install
   

INSTALLING ZLIB

Once libpcap has been installed successfully, we then move on to "zlib"
    wget http://zlib.net/zlib-1.2.8.tar.gz
    tar -zxvf zlib-1.2.8.tar.gz
    cd zlib-1.2.8/
    ./configure --prefix=/usr
    make && make install
   

Installing PCRE 8.3.6

    unzip pcre-8.36.zip
    cd pcre-8.36/
    ./configure
    make && make install

   
INSTALL PKG-CONFIG

    wget http://pkgconfig.freedesktop.org/releases/pkg-config-0.28.tar.gz
    tar -zxvf pkg-config-0.28.tar.gz
    cd pkg-config-0.28/
    ./configure
    make && make install
   
INSTALLING SNORT3++
    wget https://www.snort.org/downloads/snortplus/snort-3.0.0-a1-130-auto.tar.gz
    tar -zxvf snort-3.0.0-a1-130-auto.tar.gz
    cd snort-3.0.0-a1/
   
    export SNORT3_PATH=/opt/snort3
    mkdir -p /opt/snort3
    ./configure --prefix=$SNORT3_PATH
    make -j 8 install

    If you get the following message while making snort        
    "../src/snort: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ../src/snort)"   


   do the following:     cp /usr/lib/libstdc++.so.6 /usr/lib/i386-linux-gnu/ -v
   

RUNNING SNORT     export LUA_PATH=$SNORT3_PATH/include/snort/lua/\?.lua\;\;
    export SNORT_LUA_PATH=$SNORT3_PATH/etc/snort

Let's get the version information
/opt/snort3/bin/snort --version




Create a symbolic link for snort to /usr/bin
root@securitynik:~# ln -s /opt/snort3/bin/snort /usr/bin/snort

   
Testing the config-0 without rules
root@securitynik:~# snort -c /opt/snort3/etc/snort/snort_config.lua

Testing the default rules
root@securitynik:~# snort -c /opt/snort3/etc/snort/snort_config.lua -R /opt/snort3/etc/snort/sample.rules
When I tried the verify the configuration with the rules, I got the error above.
-- At a later time I will try to address the errors above


As a result I wanted to write my own test rule.
alert tcp any any -> any any (msg:"securitynik test rule"; sid:40000001; rev:1;)

When the configuration test with the rules was run once again, I got the following


Everything looks good so far.

Running an IDS against a pcap file   
root@securitynik:~# snort -c /opt/snort3/etc/snort/snort_config.lua -R security_nik.lua -r snort-test.pcap -A "alert_full" -q -n 10



There you go, that was my full guide on how to install and configure snort++ (snort3.0) on Kali. As I continue to learn snort 3.0 I will also continue to post materials to the blog.

Hope you enjoyed this.

References:
http://www.tcpdump.org
https://www.snort.org/documents
http://linuxmantra.com/2010/10/install-snort-2-9-on-rhel-5.html
https://code.google.com/p/libdnet/downloads/detail?name=libdnet-1.12.tgz&can=2&q=
http://luajit.org/download.html
https://code.google.com/p/libdnet/downloads/detail?name=libdnet-1.12.tgz&can=2&q=
https://www.snort.org/downloads
http://www.zlib.net
http://www.pcre.org
http://sourceforge.net/projects/pcre/files/pcre/
http://pkgconfig.freedesktop.org/releases/?C=M;O=A
http://www.linuxfromscratch.org/~krejzi/kde5/general/gcc.html
http://blog.snort.org/2014/12/project-snort-aka-snort-30.html

Splunk - Investigating a potential FTP server security incident

IOC:
File Name (and Dir Path); /valid_directory/client_file.zip
IP:192.168.0.1:

Search Query: index=main source=UDP_514 sourcetype=syslog  host="192.168.0.2" OR host="192.168.0.3" vsftpd 192.168.0.1 "/" 

above showed 37 events starting on "Jan 25 13:17:02" and ending on "Jan 25 13:25:33"

Focusing on the time range and changing the filter
index=main source=UDP_514 sourcetype=syslog  host="192.168.0.2" OR host="192.168.0.3" vsftpd AND NOT 10.0.0.1
405 events (11/26/14 1:10:00.000 PM to 11/26/14 1:25:00.000 PM)  


Jan 25 13:15:24
User connected to 192.168.0.3
Jan 25 13:15:24 192.168.0.3 vsftpd: Wed Jan 25 13:15:27 2014 [pid 3336] CONNECT: Client "192.168.0.1" 

Jan 25 13:15:24
Try to authenticate but Password failed for user "anonymous"
    - Jan 25 13:15:24 192.168.0.3 vsftpd: Wed Jan 25 13:15:27 2014 [pid 3336] FTP command: Client "192.168.0.1", "USER anonymous"
    - Jan 25 13:15:24 192.168.0.3 vsftpd: Wed Jan 25 13:15:27 2014 [pid 3336] [anonymous] FTP response: Client "192.168.0.1", "331 - Please specify the password.
    Jan 25 13:15:24 192.168.0.3 vsftpd: Wed Jan 25 13:15:27 2014 [pid 3335] [anonymous] FAIL LOGIN: Client "192.168.0.1"


Jan 25 13:15:53
  User attempted to authenticate again with a blank username
  Login failed as no user was specified
 
    - Jan 25 13:15:53 192.168.0.3 vsftpd: Wed Jan 25 13:15:55 2014 [pid 3338] FTP command: Client "192.168.0.1", "USER"
 
    - Jan 25 13:15:53 192.168.0.3 vsftpd: Wed Jan 25 13:15:56 2014 [pid 3338] FTP response: Client "192.168.0.1", "503 Login with USER first."
   
 
Jan 25 13:16:20
  user connected again
  Tried to authenticate with username "anonymous"
    - Jan 25 13:16:20 192.168.0.3 vsftpd: Wed Jan 25 13:16:23 2014 [pid 3340] FTP command: Client "192.168.0.1", "USER anonymous" 
 
Jan 25 13:16:20
  For unknown reasons the previous connection attempt was not completed as the user did not specify a password
  The user connected again
  Tried to authenticate with username "anonymous"
  User then entered 2 separate passwords but both failed
  Authentication was not successful
    - Jan 25 13:16:20 192.168.0.3 vsftpd: Wed Jan 25 13:16:23 2014 [pid 3342] CONNECT: Client "192.168.0.1"
    - Jan 25 13:16:22 192.168.0.3 vsftpd: Wed Jan 25 13:16:25 2014 [pid 3342] [anonymous] FTP response: Client "192.168.0.1", "530 Login incorrect."
   
    - Jan 25 13:16:22 192.168.0.3 vsftpd: Wed Jan 25 13:16:25 2014 [pid 3340] [anonymous] FTP response: Client "192.168.0.1", "530 Login incorrect."


Jan 25 13:16:28
    User reconnected with username "anonymous"
    Authentication failed twice as the "login" was "incorrect"
        - Jan 25 13:16:28 192.168.0.3 vsftpd: Wed Jan 25 13:16:30 2014 [pid 3346] CONNECT: Client "192.168.0.1"
       

Jan 25 13:17:02
user connected again and this time was able to authenticate successfully with username "anonymous"
        - Jan 25 13:17:02 192.168.0.3 vsftpd: Wed Jan 25 13:17:04 2014 [pid 3350] FTP command: Client "192.168.0.1", "USER anonymous"
        - Jan 25 13:17:02 192.168.0.3 vsftpd: Wed Jan 25 13:17:05 2014 [pid 3349] [ftp] OK LOGIN: Client "192.168.0.1", anon password "ftpPassword"
        - Jan 25 13:17:02 192.168.0.3 vsftpd: Wed Jan 25 13:17:05 2014 [pid 3351] [ftp] FTP response: Client "192.168.0.1", "230 Login successful."
 
    Once successful the user the user did the following:
        "SYST" - Check the system type
            - The system reported it was UNIX
        "PWD" - Print the current working directory
            - the system returned "/"
        "SIZE" - The user then tried to get the size of the file but this failed
        "CWD" - Changed working directory to "/"
        "LIST -l" - List the files in the directory, nothing showed.

    User then quit the connection
        - Jan 25 13:17:03 192.168.0.3 vsftpd: Wed Jan 25 13:17:06 2014 [pid 3351] [ftp] FTP response: Client "192.168.0.1", "221 Goodbye."
        - Jan 25 13:17:03 192.168.0.3 vsftpd: Wed Jan 25 13:17:06 2014 [pid 3351] [ftp] FTP command: Client "192.168.0.1", "QUIT"
       
       
Jan 25 13:17:22
    User connected once again
        -    Jan 25 13:17:22 192.168.0.3 vsftpd: Wed Jan 25 13:17:24 2014 [pid 3353] CONNECT: Client "192.168.0.1"    Attempt to authenticate with username "anonymous failed"
   
   
Jan 25 13:17:24

    User reonnected once again
        - Jan 25 13:17:24 192.168.0.3 vsftpd: Wed Jan 25 13:17:27 2014 [pid 3355] CONNECT: Client "192.168.0.1"    User authenticated successfully with user "anonymous"
    In addition to reruning most of the previous commands this time the user ran
        "SIZE /non_existent_directory" - get the size of the backup folder - this failed
        "CWD /non_existent_directory/" - Change directory to backup - This was successful
        "LIST -l" - List the directory - however nothing was returned
    The user then quit the session
   
   
Jan 25 13:17:44

    User reconnected
        - Jan 25 13:17:44 192.168.0.3 vsftpd: Wed Jan 25 13:17:47 2014 [pid 3358] CONNECT: Client "192.168.0.1"    authentication failed for user "anonymous"
    


Jan 25 13:17:47

    User connected again
        - Jan 25 13:17:47 192.168.0.3 vsftpd: Wed Jan 25 13:17:49 2014 [pid 3360] CONNECT: Client "192.168.0.1"    authentication was successful for user "anonymous"
    Most of the commands in the 2 previous command list were rerun
    user exited
   

Jan 25 13:18:12

    User reconnected
        - Jan 25 13:18:12 192.168.0.3 vsftpd: Wed Jan 25 13:18:15 2014 [pid 3363] CONNECT: Client "192.168.0.1"    Authentication was successful
    Once again most of the commands in the previous command list were rerun
    this time the current working directory was changed to "/valid_directory/"
        - "CWD /valid_directory/"
        - "LIST -l" - tried to view the files in the directory but this failed
    client exited
   

Jan 25 13:18:51

    user reconnected
        - Jan 25 13:18:51 192.168.0.3 vsftpd: Wed Jan 25 13:18:54 2014 [pid 3368] CONNECT: Client "192.168.0.1"    authentication was successful for user "anonymous"
    similar to previous times a number of system commands was run
        - "LIST" - tried to view the directory this was unsuccessful
    Connection failed to establish
        - Jan 25 13:18:52 192.168.0.3 vsftpd: Wed Jan 25 13:18:55 2014 [pid 3372] [ftp] FTP response: Client "192.168.0.1", "425 Failed to establish connection."   
   
After a couple of reconnects and disconnects, we have the following
   
changing the search filter to focus in on PID 3385 and expanding the time to 13:59
    index=main source=UDP_514 sourcetype=syslog  host="192.168.0.2" OR host="192.168.0.3" vsftpd AND NOT 10.0.0.1 "pid 3385"
     75 events (11/26/14 1:10:00.000 PM to 11/26/14 1:59:00.000 PM)


Jan 25 13:23:57

    The user was able to login successful with username "anonymous"
        - Jan 25 13:23:57 192.168.0.3 vsftpd: Wed Jan 25 13:23:59 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "230
        Login successful."
    The user ran most of the commands that he did previously
    Focusing on the commands relevant to session with PID: 3385
        "CWD /valid_directory/" - change directory to "/valid_directory/"
            -    Jan 25 13:24:06 192.168.0.3 vsftpd: Wed Jan 25 13:24:09 2014 [pid 3385] [ftp] FTP command: Client "192.168.0.1", "CWD /valid_directory/"
            - Jan 25 13:24:06 192.168.0.3 vsftpd: Wed Jan 25 13:24:09 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "257 "/valid_directory/""
        "LIST" - The command was unsuccessful
        "CWD bin" - tried to change to the bin directory but this failed
            - Jan 25 13:24:21 192.168.0.3 vsftpd: Wed Jan 25 13:24:23 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "550 Failed to change directory."   
            - Jan 25 13:24:21 192.168.0.3 vsftpd: Wed Jan 25 13:24:23 2014 [pid 3385] [ftp] FTP command: Client "192.168.0.1", "CWD bin"
    The user got exited to "/" root directory and then changed directory again to "/valid_directory/"

    Once in the "/valid_directory/"    directory, the user then did
        - "SIZE client_file.zip" - checked the size of the file "client_file.zip"
    The system returned the size as 4342 bytes
        - Jan 25 13:25:32 192.168.0.3 vsftpd: Wed Jan 25 13:25:35 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "213 4342"    Once the size information was received, the file was retrieved
        -    Jan 25 13:25:33 192.168.0.3 vsftpd: Wed Jan 25 13:25:35 2014 [pid 3385] [ftp] FTP command: Client "192.168.0.1", "RETR client_file.zip"
        -    Jan 25 13:25:33 192.168.0.3 vsftpd: Wed Jan 25 13:25:35 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "150 Opening BINARY mode data connection for client_file.zip (4342 bytes)."
        -     Jan 25 13:25:33 192.168.0.3 vsftpd: Wed Jan 25 13:25:35 2014 [pid 3385] [ftp] OK /valid_directory/: Client "192.168.0.1", "/valid_directory/client_file.zip", 4342 bytes, 10928.44Kbyte/sec

        -    Jan 25 13:25:33 192.168.0.3 vsftpd: Wed Jan 25 13:25:35 2014 [pid 3385] [ftp] FTP response: Client "192.168.0.1", "226 File send OK."
   
    ----- Completion of splunk investigation -----


In trying to obtain additional information to support whether or not this was a malicious attempt checks were made for other sources of the file.
   

An email was found with a file with a different (but similar name)
   
    -- The attachment in this mail was:
            "emailed_file.zip"
       
        running a "dir" on this file shows that it has the same size as reported by the FTP server which is 4342 bytes
            C:\tmp>fciv emailed_file.zip
            //
            // File Checksum Integrity Verifier version 2.05.
            //
            abe8b06f6d2670c74efa477b7d19bb77 emailed_file.zip

            dir emailed_file.zip
            ....
            11/25/2014  03:40 PM             4,342 emailed_file.zip
               1 File(s)          4,342 bytes
              
       
           
    Conclusion
        In the end this was considered a false positive, as there was enough information to suggest there was nothing malicious about this download. However, as stated many times before, the objective when investigating a potential incident is to find enough information to support your case. These information can be from sources such as packet captures, logs, emails, tickets, inventory, etc, etc.

    Hope you enjoyed this post on using splunk for your investigation
       
       
 Reference:
 http://www.nsftools.com/tips/RawFTP.htm     

Monday, December 1, 2014

Detailed analysis of an ADP Invoice Phishing Attempt - IPS (Snort) and SIEM (QRadar) Rules



In this 6 part series, we analyzed a recent phishing attempt through an email which was sent to me. In the first post we looked at the email. The second post we did an analysis using Wireshark. In the third post we did some basic static analysis. In the fourth post we performed some basic dynamic analysis. In the fifth post, we performed some basic memory analysis. In this post we put it all together writing rules for our IPS (snort) and SIEM (QRadar) devices



Now that we've perform the analysis, let's use what we've gathered to defend our infrastructure.
In post 4  we identified the following
1.            Packet 3 and 4 shows the DNS request and response for "projetglory.awardspace.com" respectively. This is similar to what was reported by InetSim.
2.            Packets 5 to 7 shows the TCP connection being setup with the host which hosting "projetglory.awardspace.com".
https://www.snort.org/
3.            Once the connection was established the HTTP GET request was made to download "/fichiers/miniuk1.pmg"
4.            In packet 11 we see this request was successful via the "HTTP/1.1 200 OK"
5.            In packet 15 and 16, we see the DNS request and response for shalhart.com.
6.            Once the name was resolved we see in packet 17-19 a connection was setup to shalhart.com.
7.            In packet 20 a HTTP GET request was made for " miniuk1.pmg". This all confirms what was shown in the InetSim log file
Writing the snort rule ...
These rules will be placed in the "local.rules" file
This rule looks for the DNS request for shahlart.com

alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"Malicious DNS Request - shahlart.com"; content:"shahlart|03|com"; classtype:trojan-activity; reference:url,securitynik.blogspot.com; Priority:1; sid:4000001;)


This rule looks for the DNS request for projetglory.awardspace.com

alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"Malicious DNS Request - projetglory.awardspace.com"; content:"|70 72 6f 6a 65 74 67 6c 6f 72 79 0a|awardspace|03|com"; classtype:trojan-activity; reference:url,securitynik.blogspot.com; Priority:1; sid:4000002;)

This rule focuses on HTTP traffic

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"ADP Phishing GET Request - shahlart"; content:"User-Agent|3a 20|mupdate"; content:"/miniuk1.pmg";  classtype:trojan-activity; detection_filter: track by_src, count 1, seconds 86400; reference:url,securitynik.blogspot.com; 
Priority:1; sid:4000003;)


Now that we have our IPS (snort) rule, let's develop a SIEM (QRadar) rule.
For this we will use a "Common Rule". A common rule is one which can run tests against either logs or flows (or both). To create this rule let's do the following:

1. From the "Offense" tab, select Rules
2. From the "Action" menu select "New Common Rule"3. Click "Next" then build the rule












































From the above we are keeping the rule simple, we are looking for traffic going to destination host 50.87.164.13 on destination port 80. In addition we 
are looking for payload that contains the string /miniuk1.pmg






















From the above rule response, the things which I configure most important are:

1. Create a new event when traffic relating to our rule is seen
2. Ensure the dispatched event is part of an offense
3. ensure an email is sent to sec@securitynik.com
4. We will also throttle the alerts to ensure we respond only 1 time per 24 hours per unique source.
5. Finally we ensure the rule is enabled






















The above represents a summary of our rule.


This concludes this series. Hope you enjoyed it as we went from the initial email which was received to analyzing enough to be able to develop rules for both our IPS (snort) and or SIEM (QRadar).



.pcap and .zip files from my analysis. Please note, in no way am I responsible for any damage caused to your computer and or other devices as a result of using these files.
adp.pcap - 4cfd352a3c890873d20a33d35fffed25  
invoice1211_pdf82.zip - 05fc7646cf11b6e7fb124782daf9fb53 

References:
http://www.snort.org
http://www-03.ibm.com/software/products/en/qradar-siem/