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).

It’s 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 firewall’s 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: Firewall’s ACL allows NAT access to an internal machine’s 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, doesn’t 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 Cbl.abuseat.org
o Xbl.spamhaus.org
o 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.

Protocol Port FW Action NATED TOWARDS Timelapse

192.168.44.104
TCP 7001 DROP 11 minutes and 24 seconds
24576-24589
UDP DROP 192.168.6.0

TCP 22 ACCEPT 192.168.44.100

Regarding TCP ports scanned

• TCP port 7001

o Officially registered at IANA for afs3-callback, there is no documentation about vulnerabilities.
o Unofficially registered for BEA WebLogic: There are know vulnerabilities and exploits.
o 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

Authorization Allow users and administrators access to administration services trough VPN.

Authentication 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).

Documentation Well written documentation about the network and security solutions in place.

Policies and Establish or improve the security policies, and create procedures to maintain this
Procedures policy.

Keep and Perform and inventory as detailed as possible about the network, the services, and
inventory their points of contact.
 Traffic Firewalls as checkpoint and Palo Alto can identify the type of traffic passing trough a
Identification 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 Perform routinely network and vulnerability scans, and hire third party companies
network to assest your network with white and black box approaches.
assessments

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_How_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