1. EAGLE Logging and Visualization Feature User's Guide
  2. Logging and Visualization Feature Description

2 Logging and Visualization Feature Description

This chapter provides a functional description of the Logging and Visualization feature.

Overview

EAGLE Logging and Visualization generates and sends log messages and UIMs from the SCCP and SFAPP cards to an external visualization server. The log messages and UIMs are converted into the JSON format with data enrichment for enhanced visualization.

The Logging and Visualization functionality provides the following features:

  • Data storage: The Log messages and UIMs are stored with data indexing.
  • Search mechanisms: Data search and data filtering are performed through data indexing.
  • Dashboards: Information is displayed and analyzed through various dashboards.

In addition, it is important to note the following points with respect to the Logging and Visualization functionality:

  • Supports up to 100K TPS with 9 VMs. If two or more VMs are down and not running, TPS gets reduced accordingly. Also, if EAGLE generates JSON over 100K TPS, data may be not reachable to Elastic Search.
  • Does not support SLIC with GTT on IPSG application and does not support SMXG cards for visualization.
  • Does not log and visualize messages for opcodes, which are not decoded on the EAGLE.

Security Support

For protection against attacks, a comprehensive approach to information security is taken.

The security of a signaling network is analyzed, which allows detection of current vulnerabilities in the network and helps in assessing information security risks.

To keep security configurations up-to-date, threats are detected early, and appropriate measures are taken. Also, it is recommended to ensure continuous monitoring and analysis of vulnerable messages that cross the network.

GSMA recommendations specify the use of a monitoring system, which can perform analysis in real time. This enables detecting phishing or anomalies in a network at an early stage.

Attacks are mostly aimed at gathering a subscriber’s information and network configuration. However, there are attacks that are likely used for fraud, traffic interception, and subscriber availability disruption.

Following are the types of attacks in a network:

  • Subscriber information disclosure
  • Network information disclosure
  • Subscriber traffic interception
  • Fraud
  • Denial of service

Fraud, traffic interception, and denial of service affect subscribers directly and may lead to significant financial losses, privacy violation, and availability disruption. Subscriber information disclosure means leakage of IMSI, disclosure of location or other data. Certain methods of subscriber traffic interception allow an intruder to tap or redirect terminating and originating calls and intercept user SMS messages. Fraud attacks can be performed against both operators and subscribers.

Subscriber Information Disclosure

Following is the type of information that could be disclosed in a subscriber information disclosure attack:

  • IMSI disclosure
  • Subscriber location discovery
  • Disclosure of subscriber profile information
  • Cryptographic material retrieval
  • Call details gathering

To obtain routing information about a subscriber during an incoming voice call, the SendRoutingInfo message is used. It must be transmitted only within the operator's home network.

To determine a subscriber's location, the ProvideSubscriberInfo message is used.

Network Information Disclosure

Network information disclosure is fraught with the leakage of SS7 network configuration data.

To obtain the relevant information, the following two messages are used:

  • AnyTimeInterrogation
  • SendRoutingInfo

Both of the messages allow network information disclosure.

Subscriber Traffic Interception

Following are the types of attacks in a subscriber traffic interception:

  • Call redirection with interception
  • SM interception/monitoring

The message UpdateLocation is used to inform the HLR about a change in a mobile switch. Terminating SMSs or calls are intercepted by sending a fake request to register a subscriber in an intruder's network. When a terminating call is received, the operator's network sends a request to a fake network to obtain the subscriber's roaming number. An attacker can send the number of their telephone exchange in response, and the incoming traffic will be transmitted to the attacker's equipment. After sending another request to register the subscriber in the real network, the attacker can redirect the call to the subscriber's number. As a result, the conversation will pass through the equipment controlled by the attacker.

The same principle is used for the interception of terminating calls via RegisterSS. However, in such a case, terminating calls are unconditionally redirected to the intruder's telephone exchange.

Originating calls are tapped by using a similar pattern. The InsertSubscriberData message replaces the address of the billing platform in the subscriber's profile stored in the VLR database. When a request is sent to the changed address, the attacker first redirects the originating call to their equipment and then redirects it to the called subscriber. Therefore, the attacker can tap any conversation of the subscriber.

Fraud

Following are the categories into which a fraud can be classified:

  • Illegitimate redirection of terminating or originating calls
  • USSD request manipulation
  • SMS message manipulation or spoofing
  • Subscriber profile modification or spoofing
  • Online charging evasion

Illegitimate Redirection of Terminating or Originating Calls

An attacker can redirect voice calls of subscribers to premium-rate numbers or to a third-party number. The call will be paid by the subscriber when establishing unconditional redirection, or by the operator when the subscriber is registered in a fake network and the subscriber's roaming number is spoofed.

Calls are redirected by using UpdateLocation, RegisterSS, InsertSubscriberData as well as by using AnyTimeModification that allows making changes to a subscriber.

USSD Request Manipulation

An attacker can transfer money from the account of a subscriber or an operator's partners by sending fake USSD requests using the ProcessUnstructuredSSRequest message. Also, UnstructedSSNotify is used to send notifications to subscribers from various services and the operator.

An attacker can send a fake notification on behalf of a trusted service containing instructions for the subscriber. That may include sending an SMS message to a paid number to subscribe to a service, calling a fake bank number due to suspicious transactions, or following a link to update an application.

SMS Message Manipulation or Spoofing

Phishing or ad messages can be sent on behalf of arbitrary subscribers or services using the MT-ForwardSM and the MO-ForwardSM methods.

MT-ForwardSM is designed for delivering incoming messages and can be used by attackers to generate forged incoming SMS messages. Unauthorized usage of MO-ForwardSM allows sending messages from subscribers at their expense.

Subscriber Profile Modification or Spoofing

A subscriber's profile stores data about the billing platform and service subscriptions. To bypass a billing system in real time, it is necessary to delete the subscriber's O-CSI subscription, which is used to make originating calls or to substitute the billing system address.

In order to prevent non-fare calls, O-CSI parameters imply that the call must be terminated if the billing platform is unavailable. However, this parameter can be changed, so that the call continues without addressing the platform. As a result, the legitimate platform does not receive information about the calls, and they are not billed.

Denial of Service

Following are the types of attacks in a denial of service attack:

  • Service unavailability for subscriber
  • Recourses depletion

If the VLR address where the subscriber is currently registered is removed from the HLR via PurgeMS initiated by a certain third-party host, terminating calls cannot be routed to the subscriber's VLR/MSC. The reason is that there is no registration address in the HLR. In such a case, originating calls are available for the subscriber because the registration record in the VLR is not changed.

Rebooting the device does not help to restore the record in the HLR, because the VLR does not initiate the UpdateLocation procedure, assuming that there are no changes in the subscriber's registration data.

It is possible to restore the registration record and the subscriber's availability only by registering in the coverage area of another serving MSC. For example, first manually selecting the network of another operator and then selecting the home network again. Another method is to move to another MSC of the home network.

Supported Message Categories

This chapter mentions the message categories that are supported with EAGLE Logging and Visualization.

Category 1

This category includes messages that should only be received from within the same network and/or are unauthorized at interconnect level, and should not be sent between operators unless there is an explicit bilateral agreement between the operators to do so.

Following is the list of vulnerable category 1 opcodes:

  • provideRoamingNumber
  • sendParameters
  • registerSS
  • eraseSS
  • activateSS
  • deactivateSS
  • interrogateSS
  • registerPassword
  • getPassword
  • processUnstructuredSS-Data
  • sendRoutingInfo
  • sendRoutingInfoForGprs
  • sendIdentification
  • sendIMSI
  • processUnstructuredSS-Request
  • unstructuredSS-Request
  • unstructuredSS-Notify
  • anyTimeModification
  • anyTimeInterrogation
  • sendRoutingInfoForLCS
  • subscriberLocationReport

Category 2

This category includes messages that should only be received from visiting subscribers home network. These should normally only be received from an inbound roamer’s home network.

Following is the list of vulnerable category 2 opcodes:

  • provideRoamingNumber
  • provideSubscriberInfo
  • provideSubscriberLocation
  • insertSubscriberData
  • deleteSubscriberData
  • cancelLocation
  • getPassword
  • reset
  • unstructuredSS-Request
  • unstructuredSS-Notify
  • informServiceCentre

Category 3

This category includes messages that should only be received from the subscriber’s visited network. Specifically, MAP packets that are authorized to be sent on interconnects between mobile operators.

Following is the list of vulnerable category 3 opcodes:

  • updateLocation
  • updateGprsLocation
  • sendParameters
  • registerSS
  • eraseSS
  • activateSS
  • deactivateSS
  • interrogateSS
  • registerPassword
  • processUnstructuredSS-Data
  • mo-forwardSM
  • mt-forwardSM
  • beginSubscriberActivity
  • restoreData
  • processUnstructuredSS-Request
  • purgeMS
  • sendRoutingInfoForSM
  • sendAuthenticationInfo
  • reportSmDeliveryStatus
  • NoteMM-Event