Fraud Hunting Platform helps solve
the following problems:
Analysis of user-device connection Group-IB's new solution identifies when compromised accounts and devices are used. For each parameter characterizing a user's interaction with the protected resource, there are other related parameters fixed by the platform. Based on these parameters and the link analysis, it is possible to detect the following:
• Multi-device access to the application via a single account
• Single device access to the application via multiple accounts
• Use of stolen/compromised accounts
• Connected devices used in fraudulent activities in other applications
Agentless malware detection Fraud Hunting Platform "catches" banking Trojans, detects unauthorized remote access, web injections, cross-channel attacks, and personal data collection. Group-IB's solution implements patented algorithms that help detect infected devices without the client's involvement and without the need to install additional software.
Group-IB Threat Intelligence & Attribution data Fraud Hunting Platform detects the latest fraud techniques, phishing preparation, and other types of attacks. The platform integrates data from Group-IB's attribution-based TI system. Exclusive information about cybercriminals, malware, adversary IP addresses, and compromised data (logins, passwords, bank cards) helps develop antifraud systems and cybersecurity teams, which allows the latter to identify intruders and their actions.
Global ID Group-IB's new solution detects new account fraud, money laundering, and social engineering. By analyzing anonymized information from various sources, Group-IB Fraud Hunting Platform creates a global user profile embracing all online channels. Understanding the connections between users, accounts and devices helps distinguish legitimate customers from fraudsters, while the combination of Group-IB Fraud Hunting Platform with unique Threat Intelligence & Attribution data makes it possible to identify hidden threats and suspicious connections.
Cross-channel protection Fraud Hunting Platform detects and blocks cross-channel attacks as well as card-not-present fraud (CNP). Web Snippet and Mobile SDK correlate data on user behavior on their devices when working through various channels of interaction with the bank and identify a wide range of cross-channel attacks, including attacks on third-party platforms that are most vulnerable to CNP attacks, such as online shopping platforms. Group-IB's Fraud Hunting Platform script can be embedded into the 3-D Secure system code to detect cashing from cards stolen by scammers or using phishing payment sites.
Group-IB Fraud Hunting Platform
reduces costs thanks to:
- Alternative to Captcha to improve conversion
- Adaptive authentication and no unnecessary checks when logging in
- Adaptive confirmation of transactions
- Lower cost of sending SMS messages and other means of two-factor authentication
- Fewer calls to customers to confirm transactions
- No unnecessary steps during user authentication
- Higher operations limit
Implementing Group-IB's Fraud Hunting Platform To enable protection against bots, Web Snippet (for web portals) or Mobile SDK (for mobile apps) must be implemented as part of Group-IB Fraud Hunting Platform.
Preventive Proxy can be deployed within the application infrastructure or the Group-IB cloud. Proxying requests can be configured through Preventive Proxy or the auth-request module in NGINX.
Delivery options:
- Docker container
- Binary executable file
- Group-IB cloud
Traffic can be processed by:
- Proxying requests through Preventive Proxy
- Marking up with auth-request in NGINX
Proxying requests through Preventive Proxy Preventive Proxy can be integrated into the application infrastructure as
a loop on the load balancer. In such cases, the Preventive Proxy will receive the entire user requests (headers and body) from the balancer and send the verdict back in response.
It can also be integrated using the
gap between the load balancer and the application backend. In such cases, the Preventive Proxy verdict will be processed on the application backend. For static content, filtering and redirection can be configured to the application backend. For a load of 20,000 to 30,000 requests per second (excluding static content), the following minimum server resources are required:
- CPU 4 cores, 2 threads per core
- RAM 8 GB