Professional Documents
Culture Documents
Rafael Torrales Case Analysis
Rafael Torrales Case Analysis
of a SIEM alarm
Rafael Torrales
April-2016
Summary:
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.
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.
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.
After applying a whois and checked SrcIP address, we got the following results:
Figure 2 IP address reputation
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.
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.
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.
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.
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.
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.
Authorization Allow users and administrators access to administration services trough VPN.
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
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:
http://www.zonksec.com/blog/hands-on-with-weblogic-serialization-vulnerability/
https://www.giac.org/paper/gsec/312/firewalk-attackers-firewall/100588
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
SpamHause: https://www.spamhaus.org/