Analysis of a SIEM alarm

Rafael Torrales
April-2016

Summary:
Based on a SIEM alarm, analysis of the events has been requested.
There were several connection attempts from one external IP address witch resulted in a
SIEM alarm, upon further analysis, the Source IP address seems to be from Seoul, Korea
and attempting several connections towards a couple of different UDP and TCP ports.

Data description:
The ports connections initiated from this Source IP address (SrcIP) are TCP and UDP.

TCP connections are towards port 7001

UDP connections are towards ports from 24576-24589

All this connection attempts are being all dropped with but one, the last one in this log,
towards port 22 and being NATED towards internal IP address 192.168.44.100.
All events displayed were in a lapse of 11 minutes and 24 seconds between the first
event started until the last event ended.
In order to have a better conceptualization of the events, here is a basic and simplified
network diagram with the event. We can see all connections are dropped at firewall level
with exception of 1, towards port 22. We can also see the NAT destinations.

Figure 1 General Network Topology based on events received

Because this logs contain internal network destination addresses, we can interpolate that
we are receiving logs from a firewall inside the network and NOT a firewall on the
perimeter.
1 Observation: Regarding Network Translation.

Because destination addresses are internal networks as we can see in the logs, the
firewall is either doing STATIC NAT by itself or other device up into the perimeter network
is doing it before this firewall (FWSM @ 192.168.6.100).
Its important to note that some packets are addressed towards destination IP (DestIP)
(192.168.6.0, this is not a valid IP address, but a reserved IP address to specify networks,
for example, we could specify a network like 192.168.6.0/24, we need to provide a
network mask).
Its also more plausible the SIEM solution is configured to count events destined to a
network segment in this way.
Depending on the rules defined on the perimeter firewall, the logs generated by the
FWSM (internal firewall) may not reflect all the connection attempts generated by SrcIP
Actions:

Check perimeter firewalls logs and correlate public ip addresses with the
translated internal addresses.
Check if other connections attempts from this SrcIP are being blocked by the
perimeter firewall.
Contact Firewall Administration team and ask more information about this port
translation, check SIEM events counting configuration.

2 Observation: Firewalls ACL allows NAT access to an internal machines TCP

port (ssh:22) used for administrative purposes from potentially any source.
As the logs displays the firewall were blocking attempts to different services based on an
ACL list, why is this SrcIp authorized to perform SSH?.
Port TCP 22 is mainly used for administrative purposes and secure file transfers, (can also
be used for performing reverse proxy).
The SSH is considered a very secure protocol, and in years not a lot of exploitable
vulnerabilities have been discovered, and quickly patched.
Unskilled Malicious attackers will typically not attempt to exploit the SSH service, but
instead they will continuously scan Internet for machines listening on TCP 22 and perform
dictionary attacks.

Actions:

Contact Firewall Administration team and ask more information about this firewall
NAT rule.

Check firewall logs for matches on that rule. Identify If its normal a remote user
from Korea accessing trough SSH.
A firewall rule allowing SSH, doesnt mean that the target device is necessary
listening on that port. Check if the target machine have the SSH port running. If
the target machine is not listening to that port this could mean that the SrcIP is
performing a scanning attack.

3 Observation: Source IP details and reputation

After applying a whois and checked SrcIP address, we got the following results:

IP found to be from South Korea.

Whois information here: http://whois.domaintools.com/1.234.39.198

Figure 2 IP address reputation

Checks SrcIP on Multiple BlackLists http://ipindetail.com/ip-blacklist-checker

This ip is being already blacklisted on 3 websites.
o
o
o

Cbl.abuseat.org
Xbl.spamhaus.org
Zen.spamhaus.org

Figure 3 Blacklist check results

Actions:

This IpSrc IP address is already a known abuser, check perimeter firewall logs to
check if there is any other traffic from or towards that SrcIP
If the SrcIP is considered found in the logs, and considered valid at perimeter
firewall, evaluate further blocking this ip address.
Block IpSrc at perimeter level.

4 Observation: Ports used and time lapse.

TCP port scanning is more common than UDP port scanning, for an important reason, TCP
connections are reliable while UDP connections are not. Because of this reason, an
attacker must have a good reason for trying to scan or use UDP ports, UDP scanning is
slow and not reliable.
Protoc
ol

Port

FW
Action

TCP

7001
24576-24589

DROP
DROP

192.168.6.0

22

ACCEPT

192.168.44.100

UDP
TCP

NATED TOWARDS
192.168.44.104

Timelapse
11
minutes
seconds

and

24

Regarding TCP ports scanned

TCP port 7001

o
o
o

Officially registered at IANA for afs3-callback, there is no documentation about

vulnerabilities.
Unofficially registered for BEA WebLogic: There are know vulnerabilities and
exploits.
Used by several Trojans.

Figure 4 port 7001 current registration and known usage.

Regarding UDP ports scanned: 24576-24589

o Belongs to Registered Port list, and is currently unassigned
o Could be WiNG 5 Firewall Port Usage.
o Could be Cisco Unified CallManager 5.1 TCP and UDP Port Usage

Questions:
SIEM alert from a firewall log. Can you identify what the alert is for?

Based on the analysis performed, I think the the alert was generated specifically because
there was one successful connection towards a port after several dropped connections.
That means SIEM is alerting a reconnaissance attack who passed the perimeter network
and successfully found an open port, who with the current information may or may not
have a listening device on it.

What could the potential severity be?.

To give an accurate severity, we need more information.
Based on the current events given, its to early to jump into conclusions.
If that not enough, and a potential severity of a network scan of this magnitude is, I
would say, current impact is LOW and Likehood of being a network scan is MEDIUM.
Overal Risk Severity: LOW

Figure 5 Severity table

There is not enough data for determine severity, further investigation is required.
This is either a very specific target attack, or a very unskilled and untargeted.

If the fact the IP address is registered on several blacklists (being on a black list
leave the attacker almost no space for being a skilled targeted attacker), but I
would use that information to profile it as an attacker trying to exploit a newly
discovered vulnerability.
The attacker is performing some specific scanning attacks.
The attacker my be already aware of the multi firewall infrastructure and currently
performing a Firewalk scanning attack, wich consist into abusing TTL to identify
open ports by the different layers of firewalls.
This could even be a remote administrator who is using a proxy service and tried
to access remotely, without realizing the connections are being dropped because
of an ACL.

What would your next action be

There is always space for improvement, here is a list of things to improve and reduce risk
for this case scenario.
Depending on the company size, this tasks can be under different teams.
Security

Proposed Action

Authorizatio
n

Allow users and administrators access to administration services

trough VPN.

Authenticati
on

Implement two factor authentication to reduce risk of a bruteforce

attack.

Log Analysis

Check source IP address for any other activity.

Check on the ACL what are the allowed Source IP addresses (if any).

Documentati
on

Well written documentation about the network and security

solutions in place.

Policies and
Procedures

Establish or improve the security policies, and create procedures to

maintain this policy.

Keep and
inventory

Perform and inventory as detailed as possible about the network,

the services, and their points of contact.

Traffic
Identification

Firewalls as checkpoint and Palo Alto can identify the type of traffic
passing trough a connection.

Traffic
captures

Specific devices (IDS/IPS/Fireeye/Checkpoint/Palo Alto) can capture

traffic passed on the network, and analyst can retrieve copies of
traffic and perform analysis locally (with Wireshark).
Depending on the security requirements, some solutions may
capture all the network traffic and store it for a period of time, other
may capture traffic based on triggered events (an IPS rule being
triggered).

Perform
proactive
network
assessments

Perform routinely network and vulnerability scans, and hire third

party companies to assest your network with white and black box
approaches.

How would you resolve this

As already mentioned, the way to resolve this issue, involves obtaining more data from
the available sources.
Obtain better visibility of the potential attack by searching on related logs at the
perimeter firewalls
Check if there is any machine on the DstIp for the SSH connection and check if its
listening on port TCP 22, if not close that port.

References:

Weblogic: Hands on with WebLogic Serialization Vulnerability

http://www.zonksec.com/blog/hands-on-with-weblogic-serialization-vulnerability/

Firewalk : Can Attackers See Through Your Firewall?

https://www.giac.org/paper/gsec/312/firewalk-attackers-firewall/100588

Risk Rating: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

Port Scanning Techniques: https://nmap.org/book/man-port-scanning-techniques.html
Wing 5 references:
https://atgsupportcentral.motorolasolutions.com/content/emb/docs/manuals/WING5X_Ho
w_To_DHCP_Rev_A.pdf
Cisco call manager:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/port/5_1/51plrev1.pdf
CBL Lookup: http://www.abuseat.org/lookup.cgi
SpamHause: https://www.spamhaus.org/
TCP port activity: https://isc.sans.edu/port.html?port=7001