LogSentinel SIEM for
Website Integrity Monitoring

Prevent data breaches through your website frontend

Website Formjacking (or Magecart) attacks are becoming mainstream and result in revenue and reputation loss and regulatory fines. In those attacks, malicious actors manage to inject scripts that scrape credit card and credential data from your website.

LogSentinel SIEM has a dedicated integrity monitoring module that alerts you for any script change without the need to modify your website. Get your site protected from formjacking at reduced operational cost and minimize effort on audit and forensics.

Support For Every Website

LogSentinel SIEM work regardless of the technologies chosen to build the website, as it only monitors the frontend.

Threat
Detection

Discover anomalous script changes with malicious payloads in near real-time and react immediately to prevent damage

Straightforward Integration

No need to change your website, just add the URL and configure test credentials for protected pages.

Data Insights and visualizations

Gain insights by analyzing correlated data from your website script changes and other  sources with flexible custom queries and charts

Website Integrity Monitoring Use Cases

Credit Card Theft​

Credit Card Theft

Stop criminals from stealing customer credit  card information

Credential Threft​

Credential Theft

Stop malicious actors from obtaining customer and employee credentials

Regulatory Compliance​

Regulatory Compliance

Improve your compliance with security and privacy regulations (e.g. GDPR, HIPAA)

Sensitive Data Leaks​

Sensitive Data Leaks

Don’t let attackers use injected scripts to leak sensitive corporate data

Magecart Protection​

Magecart Protection

Magecart is a specific form of formjacking that is affecting thousands of websites

Website Formjacking FAQs

What threats do LogSentinel SIEM protect against?

Malicious actors can modify scripts that run on your website in order to steal your users’ data (credentials, credit card details, etc.). British Airways and Ticketmaster are the most notorious such attacks. They can happen in multiple ways:

  • A 3rd party script hosting (e.g. CDN) gets compromised
  • Your own static resource server gets compromised
  • An attacker performs a man-in-the-middle-attack a thus modifies a script from an otherwise uncompromised server
    LogSentinel SIEM solve those by monitoring your scripts for unexpected changes and alert you when they happen.

Which pages should I monitor?​​

You can monitor any page, but it’s best to monitor the following:
  • Homepage – if the page your users land on is compromised, then an attacker can do anything to trick them into submitting sensitive data. Since you are most likely reusing templates, monitoring the homepage scripts will mean monitoring the scripts on most pages
  • Login page – this is where an attacker can get hold of your users’ credentials
  • Payment page – the most lucrative data is credit card details, so monitoring the payment page scripts is key. Your payment page may not be directly reachable from a specific URL, so you may have to manually monitor each script on that page
  • Should I scan pages or scripts?​​

    LogSentinel SIEM support both. For public pages, it’s good to scan the whole page, whereas for pages that are not reachable directly via a GET request (e.g. the payment page), you can monitor scripts individually.

    Why is this better than a Subresource?​​

    • It complicates build automation as you have to recalculate hashes of bundled and minimized scripts and inject them into page templates
    • Minor changes in a script can break your entire website
    • It doesn’t load with dynamically loaded scripts
    • If your main server is compromised, the attackers can easily update the script hash

      LogSentinel SIEM is simple to set up, doesn’t break your website but rather alerts you in case of changes, it works with dynamically loaded scripts and even if an attacker has a control on the system, they can’t stop the monitoring. While they can serve a different version of the script to our IPs that’s a more complicated step than changing the script hash. It may seem strange that an attacker with access to the main server would inject javascript rather than breach the database, but credit cards aren’t usually stored in the plain text there and it’s easier to collect them through a well-tested malicious frontend script than to modify custom code.

    Isn't Content-Security-Policy (CSP) enough to protect me from malicious scripts?​

    No, CSP only defines the trusted domains, but this is exactly how breaches happen – a trusted domain gets compromised and starts serving modified malicious scripts. You should still use CSP for additional protection, of course. CSP can be used to whitelist trusted domains that the website sends data to, thus limiting the ways a malicious script can send the data to the attackers, but that’s very tedious to configure right and it still leaves several options (e.g. sending the browser to a malicious page and passing the data as GET parameters).​

    Will monitoring slow down my website?​​

    No, the scans are gentle and don’t involve heavy server-side operations on your end.​

    Insights

    CONTACT US

    If you would like to clear compliance and boost the information security of your business, using a next-gen SIEM, that combines log management, behavior analytics (UEBA), threat detection and incident response into a complete security monitoring platform, get in touch now!