Wrap-up: Hack-Lab 2017#2

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements. This hack-lab took place in our office in Bern.

 

Topics

The following topics, tools and technology has been discussed during this Hack-Lab:

  1. Threat Modeling and Security Concept session
  2. CMS Assessment
  3. JWT4B development
  4. GnuRadio door bell analysis
  5. Windows Share Enumeration Tool
  6. Exploit.courses testing and training

Wrap-Up

Topic #1 -Threat Modeling and Security Concept session

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his knowledge about threat modeling and security concept creation and analysis with colleagues.

Information Security fundamentals:

  • Security Foundations – CIA
  • Security Design Principles
  • Threat Modeling and Standards

Security Concepts:

  • Ownership and Data Classification
  • Architecture and Network Topology
  • Web Security Controls
  • Operational Security

Topic #2 – CMS Assessment

Using different available security and hardening scanners, we try to asses the security of three CMS: Drupal, Joomla, WordPress.

The goal is to find new vulnerabilities and possible test cases. We refresh and update our Compass Knowledge and improve our tool-set for CMS security assessments.

Technology:

  • Drupal
  • WordPress
  • Joomla
  • Web Scanners written in Python

Topic #3 – JWT4B development

We create a Burp plugin which helps the analyst testing apps which uses JSON Web Tokens (jwt.io).

The first step, which we performed in the previous hacklab, was to create a basic prototype, which enables Burp to visualize the tokens. During this hacklab we increased the functionality, implemented signature checking and interception functionalities.

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which enables him to modify the JWT token comfortably:

Technology:

  • Java
  • JJWT (library)
  • JWT

Topic #4 – GnuRadio door bell analysis

We analyzed a wireless door bell with the help of GnuRadio and HackRF One. We captured the ASK modulated signal, and stored it as digital bitstream in a file. Afterwards we could successfully replay the stored bitstream, making the door bell ring. The next step will include to further analyze the bitstream. 

Technology:

  • GNU Radio
  • HackRF One SDR
  • Kali Linux

Topic #5 – Windows Share Enumeration tool development

If a pentest is performed in a large environment, it is possible that hundreds of accessible Windows shares are available in the network. The goal is to create a tool, which supports us during our penetration tests. Our tool should display the following information for every share in the network:

  • IP Address
  • Hostname
  • Share Name
  • 20 top level files and directories
  • ACLs for the top level files and directories

We managed to implement this tool by combining  Linux Samba tools (smbclient, smbcalcs) in an advanced shellscript.

Technology:

  • Windows, filesharing, network share
  • ACL, Permissions
  • masscan
  • samba / smbclient / smbcacls
  • Linux, Shell, Scripting

Topic #6 – Exploit.courses testing and training

Dobin Rutishauser teaches the “Exploiting & Defense” part of the Application- and Software-Security module at the Bern University of Applied Sciences (Berner Fachhochschule). For this assignment he created a website which provides writeups and challenges to be solved by the students. It also hosts dedicated per-user Linux container, accessible via JavaScript terminal. The Hack-Lab was used to check the website for usability problems, resistance against local DoS attacks, security problems and also basic functionality checks. We also performed a review of some of the writeups, where the team members solved several of the challenges. This includes the ARM buffer overflow challenge, and an extended version of the shellcode development challenge.

The team could identify several small bugs, some small mistakes in the writeups, and gave valuable usability improvement feedback.

Technology:

  • qemu, LXC / LXD
  • x86, x64 and ARM
  • gdb, readelf and python
  • AngularJS and go

Wrap-up: Hack-Lab 2017#1

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements.

   

Topics

The following topics, tools and technology has been discussed during this Hack-Lab:

  1. SharePoint Security
  2. Bypassing Android 7.0 HTTPS Apps Certificates Restriction
  3. JWT4B
  4. CodeInspect
  5. Smart Meter
  6. DNS Tunnel Debugging

Wrap-Up

Topic #1 – SharePoint Security Lab and Knowledge Sharing

SharePoint is a very popular browser-based collaboration and content management platform. Due to its high complexity, proprietary technology and confusing terminology it is often perceived as a black-box that IT and security professionals do not feel very comfortable with.

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his research work with colleagues. They challenged his findings and shared their thoughts on pros & cons of security relevant settings. The outcome of this Hack-Lab session will be shared in a series of blog posts within the next couple of weeks.

The research in our very own hands-on SharePoint lab allows us to gain an in-depth understanding of any type of SharePoint environment, be it a purely internal collaboration web application, a platform to share information with external partners or a publishing site hosting the company website. To build or assess a secure SharePoint environment one needs to understand the importance of governance, logical and physical architecture, network topology, active directory considerations, authentication and authorization, segregation of classified data, hardening and most importantly web security relevant settings to make sure the built-in protection measures are effective. Like other modern Microsoft products, an out-of-the-box SharePoint installation can be considered secure. However, there are so many weirdly named settings which heavily depend on each other that misconfiguration is likely to happen, leaving the door wide open for unauthorized access by adversaries with SharePoint skills.

TECHNOLOGY:

  • SharePoint Server 2010 & 2013
  • Web Applications, Site Collections, (Sub-)Sites, (Custom) Lists, Document Libraries, Web Part Pages, Web Parts, Apps
  • Web Security, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF)
  • Navigation Links
  • Web Sensitive Files, permission to Add & Customize Pages and Scriptable Web Parts, e.g. Content Editor and Script Editor (“SafeAgainstScript=False”)
  • Browser File Handling
  • Web Page Security Validation (aka Anti-CSRF token)
  • Lockdown Mode Feature
  • Remote Interfaces SOAP, CSOM, WCF Service, REST Interface
  • Server-Side Controls
  • .NET Sandboxing, Sandboxed Solutions and Apps
  • Self-Service Site Creation
  • Developer Dashboard
  • Audit Logs
  • People Picker

Topic #2 – Bypassing Android 7.0 HTTPS Apps Certificates Restriction

With Android 7.0, apps do not trust user imported certificates anymore.  Intercepting app network traffic with a proxy has become more complicated.

The goal is to find or create a custom application which is explicitly developed for Android 7.0. Then to configure the app with the network_security_config.xml file, which is used to bypass this restriction,  and therefore enables user defined certificates.

Technology:

  • Android Studio
  • Android 7.0
  • Apktool

Topic #3 – JWT4B

Create a Burp plugin which helps the analyst when testing an app that uses JSON Web Tokens (JWT.IO).

Frist step is to create a prototype which enables Burp to visualize the tokens. On further hacklabs it should be possible to automatically perform JWT attacks.

Technology:

  • Java
  • JJWT (library)
  • JWT

Topic #4 – CodeInspect

Evaluation of CodeInspect’s features.

Determine if CodeInspect could be used to make future  Android app analysis assessments more efficient.

Technology:

  • Java
  • Android

Topic #5 – Smart Meter

Description:

An Energy Monitoring System was provided for testing. It is used to measure the current consumption and provides various interfaces. Web browser (TCP/IP) and Modbus are the main ones.

Assess the security of the interfaces. What can an attacker exploit if given network access to the device?

Technology:

  • TCP/IP
  • Modbus
  • HTTP Web Application

Topic #6 – DNS Tunnel Debugging

Compass Security has its own trojan toolkit which we use for responsible phishing attacks in mandate for our customers, and also demos and proof of concepts. The trojan also implements DNS tunneling.

Analyze the source code and perform debugging to identify and fix some reliability issues while performing DNS tunneling with multiple clients.

Technology:

  • C++

SAMLRequest Support for SAML Raider

About a year ago, the Burp extension SAML Raider [0] was released as a result of a bachelor thesis [1] in collaboration with Compass Security. This Burp extension automates most of the steps, which are necessary to test a SAML single sign-on process and perform according attacks. With SAML Raider, an authentication bypass vulnerability in a Service Provider was found [2]. More information is available in our first blog post about SAML Raider here: SAML Burp Extension [5].

We did some bugfixing and added new features to SAML Raider in the past year. In version 1.2.0, we introduced the new ability to intercept and edit SAMLRequest Messages. The current version is 1.2.1, which is available here [3] on GitHub. It will also be in the official Burp Suite BApp store [4] shortly.

Decode SAMLRequest Message

There are several Burp Extensions [6] like SAML ReQuest [7], SAML Editor or SAML Encoder which allows you to edit SAMLRequests. We also got asked [8] if this feature is supported in SAML Raider, which was not the case. Because this would be a nice feature, we implemented it in version 1.2.0.

What is a SAMLRequest?

A SAMLRequest is the SAML message, which is sent from the user (browser) to the Identity Provider, to “ask” for an assertion. Usually, the SAMLRequest is sent to the Identity Provider, which will respond with a login form to ask for the credentials. If the login was successful, the SAMLResponse is sent back to the client, which is then forwarded to the Service Provider.

A SAMLRequest is sent via POST to the Identity Provider and looks like this:

samlrequest

So, it’s quite clear, that this is not so practical for quick editing and testing.

SAMLRequest in SAML Raider

SAML Raider is now able to properly decode a SAMLRequest and display it in the SAML Raider tab:

samlrequest_samlraider

Now it is very easy to modify the SAMLRequest. The SAMLRequest is automatically encoded back in it’s original format and forwarded to the target, if the Forward button is clicked.

But why do you need to view/edit the SAMLRequest? With this new feature, you can read what the client is sending exactly to the Identity Provider and perform fuzzing or testing the Identity Provider itself.

So, if you have any questions, issues or features requests, don’t hesitate to contact us or open an Issue on GitHub [0].

References

Making of Compass bIOTech v1.0

The “Internet of Things” (IoT) grows quickly. More and more devices are connected to the Internet to automate tasks and simply life. Fridges automatically order milk, cars are taught to self-drive via a simple update and bridges send live updates about their structural integrity.

According to Gartner’s 2016 Tech Trends, IoT will define the shape of tomorrow’s business. At Compass, we also appreciate the impact of connected devices in the near future, in terms of how they can make our lives easier, and how they can make our information more exposed. With this in mind, we recently opened a new security training on the basics of IoT and their vulnerabilities.

Compass bIOTech v1.0 is our own piece of Hardware in the grand IoT puzzle of devices. This smart device has been designed to measure the moisture level of plant pots using a capacitive sensor. It then connects to the cloud (Hacking-Lab) and an e-mail alert can be sent in case of low humidity level.

But before it reached its v1.0 state, the Compass bIOTech sensor went through multiple stages of development between an original idea and its realisation:

1 – Idea

To give a little life to your office, or to make your living room livelier, green stuff is always a nice addition to your everyday environment. Problem: these things need attention! We all at some point forgot to water a plant, and came back after a day, a weekend, or a longer holiday to find it dried out.

imag0048

The plant of Ivano, at Compass Office Bern

At Compass, we decided to tackle this problem and to grow ourselves a green thumb, green like a circuit board! With no time to spare, Reto Schädler started the design, with a few necessary features in mind:

  1. one must be able to configure the device’s humidity threshold,
  2. a status should be readable directly on the device,
  3. the thing must communicate with a cloud,
  4. the battery should last long.

2 – Circuit Board Design

Schema Compass bIOTech v1.0

Schema Compass bIOTech v1.0

The capacitive humidity sensor consists of a circuit path that is charged via the resistor R5. Using this, we can measured how long it takes until the voltage is half of the operating voltage.

The 32bit ESP8266 Microcontroller Chip is based on the Arduino development environment and has built in Wifi capabilities. It requires an operating voltage of 3.0 – 3.6 Volt and runs at 80MHz.

Since the two AA-Batteries have a voltage level at max. 3V, a Step-Up Convert to 3.3V is necessary. And because of the required battery life time, a Wake-Up chip is used to cut power supply via MOSFET.

Versuchsaufbau Compass bIOTech v1.0

Prototype Compass bIOTech v1.0

3 – Realisation

pcb_both

Left: PCBA 3D Altium Designer, Right: Compass bIOTech v1.0 PCBA

In configuration mode, the chip serves as a Wifi AP and provides DHCP to connecting devices and a web GUI for configuration purposes. In measurement mode, the device connects to the configured SSID/password and submitts moisture level, battery level and firmware version to a dedicated Hacking-Lab services.

 

4 – Where to get your own bIOTech device

We will be giving away a first bunch of bIOTech devices at Swiss Cyber Storm on October 19th in Lucern. Visit the conference and walk by our both. We will be glad to equip you with your own green thumb.

For those who can’t make it to the conference, stay tuned and sign-up for our next IoT security training where we will tinker with the devices interfaces and security issues.

 Grab’em while they’re hot!

Windows Phone – Security State of the Art?

Compass Security recently presented its Windows Phone and Windows 10 Mobile research at the April 2016 Security Interest Group Switzerland (SIGS) event in Zurich.

The short presentation highlights the attempts made by our Security Analysts to bypass the security controls provided by the platform and further explains why bypassing them is not a trivial undertaking.

Windows 10 Mobile, which has just been publicly released on 17th March 2016, has further tightened its hardware-based security defenses, introducing multiple layers of protection starting already at boot time of the platform. Minimum hardware requirements therefore include the requirement for UEFI Secure Boot support and a Trusted Platform Module (TPM) conforming to the 2.0 specification. When connected to a MDM solution the device can use the TPM for the new health attestation service to provide conditional access to the company network, its resources and to trigger corrective measures when required.

Compared to earlier Windows Phone versions, Windows 10 Mobile finally allows end-users without access to an MDM solution or ActiveSync support to enable full disk encryption based on Microsoft BitLocker technology. Companies using an MDM solution also have fine grained control over the used encryption method and cipher strength. Similar control can be applied to TLS cipher suites and algorithms.

Newly introduced features also include the biometric authentication using Windows Hello (selected premium devices only for the moment) or the Enterprise Data Protection (EDP) which helps separating personal and enterprise data and serves as a data loss protection solution. EDP requires the Windows 10 Mobile Enterprise edition and is currently available to a restricted audience for testing purposes.

Similar to Windows 10 for workstations the Mobile edition automatically updates. Users of the Windows 10 Mobile Enterprise edition however have the option to postpone the downloading and installation of updates.

In addition the presentation introduces the Windows Bridges that will help developers to port existing mobile applications to the new platform. While a preview version for iOS (Objective C) has been made publicly available, Microsoft recently announced that the Windows Bridges for Android project has been cancelled. In the same week Microsoft announced the acquisition of Xamarin, a cross-platform development solution provider to ease the development of universal applications for the mobile platform.

The slides of the full presentation can be downloaded here.

References:

This blog post resulted from internal research which has been conducted by Alexandre Herzog and Cyrill Bannwart.

Presentation on SAML 2.0 Security Research

Compass Security invested quite some time last year in researching the security of single sign-on (SSO) implementations. Often SAML (Security Assertion Markup Language) is used to implement a cross-domain SSO solution. The correct implementation and configuration is crucial for a secure authentication solution. As discussed in earlier blog articles, Compass Security identified vulnerabilities in SAML implementations with the SAML Burp Extension (SAML Raider) developed by Compass Security and Emanuel Duss.

Antoine Neuenschwander and Roland Bischofberger are happy to present their research results and SAML Raider during the upcoming

Beer-Talks:
– January 14, 2016, 18-19 PM, Jona
– January 21, 2016, 18-19 PM, Bern

Free entrance, food and beverage. Registration required.

Get more information in our Beer-Talk page and spread the word. The Compass Crew is looking forward to meeting you.

Aftermath of the Netgear Advisory Disclosure

Update – 13.10.2015: Netgear published a new firmware (version 1.1.0.32) which fixes the reported authentication bypass.

My most recently appointed colleague, Daniel Haake, described in the previous blog article “Authentication Bypass in Netgear WNR1000v4 Router” how he found an authentication bypass in commonly used Netgear firmwares. Due to the rediscovery of the issue and its public disclosure, we decided to go public despite the fact Netgear did not yet release a fix for the identified security hole.

Shortly after the release of the Compass advisory on public mailing list Bugtraq, we were contacted by Joe Giron, who experienced troubles with his Internet connection around September 27th. On September 28th, Joe noticed that his Netgear router’s primary DNS server had been set to point to a non-standard DNS server. This timeframe means that attackers were active before the release of Shellshock Lab’s blog article (which is detailing the same vulnerability). Joe mentioned that the remote administration interface of his Netgear router was accessible via the Internet, but protected by a strong password. He therefore had high suspicions that he fell victim of an attack against an unpatched vulnerability in his router. The release of our advisory was the confirmation and technical explanation of it.

The IP of the rogue DNS server set in his router did not only expose a DNS service, but also a web server. This web server served various PHP scripts, log files and text files. The logs contained over 17’000 entries of presumably hacked routers, including their IP address, username and password of their administration interfaces. A further analysis of this list would identify more than 11’000 unique routers.

netgearpasswords

As we discovered that this authentication bypass was being exploited in the wild and that over 10’000 users were affected, we contacted Switzerland’s CERT for further help. GovCERT was very helpful and took over the case by

  • Attempting to contact Netgear again to urge them to release the patch
  • Analyzing the logs of the web server and identifying the victims
  • Taking down the command and control server to avoid further infections
  • Liaising with GovCERT’s partners worldwide to notify the Internet service providers of the victims

In the meantime, the media got interested in the advisory and Threatpost published yesterday evening an article about the flaw and its follow-up. A second person reached out to us after the publication of this article, describing the same infection vector as well as the same IP address for the DNS and C&C server. We are currently in contact with other media outlets and will update this section when further articles are released.

The debate between responsible- and full disclosure is endless and both approaches have their pro- and cons. At Compass Security, we attempt to get the best balance between these two approaches. We are confident that our approach of leaving some time for the vendor to patch the vulnerability before publicly disclosing the issue in case of no adequate response was the best. Public information has proven to work and helped identifying ongoing attacks. Coordination with the relevant authorities allowed coordinated action against the attackers and will hopefully help the victims of this hack.

Media Update, 11.10.2015:

Media Update, 12.10.2015:

IP-Box – Why a 4 digit passcode is still a bad idea

Up to the iPhone 4, 4 digit passcodes could be brute-forced within a short amount of time – maximum 30 minutes, depending on the passcode. With the iPhone 4s, the Boot ROM vulnerability required to upload a custom RAM disk has been closed thus rendering newer phones immune to this attack.

This is where the IP-Box comes in. The IP-Box is small box which can be ordered with various adapters for iPhones up to the iPhone 6 (Plus). The device is powered by the iPhone battery and has a light sensor to detect if the iPhone has been unlocked. The box comes at a price tag of around CHF 250, including the iOS8 adapter.

While there is only sparse documentation available for the box itself – most of it being in Chinese – Detective Cindy Murphy from the Madison Police Department created a manual which serves as an excellent starting point (iP-BOX: Breaking Simple Pass Codes on iOS Devices).

There are several modes of operation for brute-forcing the passcode. Besides the obvious sequential counting from 0000 to 9999 or from 9999 to 0000, the software allows for different pattern-based attacks – i.e. birth dates, patterns or ordered lists – slashing the time needed to crack the code.

Compass Security ordered the Box and tested if it lives up to its expectations. The hardest part of cracking the passcode was actually opening our test devices where the iPhone 5 actually resulted in a broken suction cup.

The first test subject was an iPhone 4 running iOS 7.1.3. For iOS 7 the device luckily does not need to be opened, the IP-Box and its light sensor can be attached and the device is ready to get pwned. The passcode can even be cracked if the phone is in the disabled mode. This state normally would no longer allow manually entering passcodes and requires the iPhone to be connected to iTunes to get it back to a working state.

We set the “Each group of data interval (ms)” to 4500 while leaving the “Stop while the brightness changes” and “Each time interval bit (ms)” at their respective default settings. We found that faster passcode guessing rates lead to unsuccessful passcode tries. With the above settings the box managed to enter 1 passcode per 6 seconds which means that in the worst case, cracking a 4 digit passcode would take about a day on an iOS 7 device.

As our video shows, the IP Box was not overly impressed with the fact that the iPhone 4 was disabled.

The second and third test subjects were an iPhone 4s and an iPhone 5 each running iOS 8.1. This is the last version currently supported by the IP Box. With iOS 8 a special adapter is needed and the device needs to be opened in order to disconnect the iPhone’s battery and connecting the IP-Box directly to the power connector of the device. This setup allows the IP Box to aggressively cut the power supply, preventing the iPhone from increasing the counter on failed passcode attempts.

Since the iPhone restarts after every passcode guessing attempt, in addition to the parameters used on the iOS 7 device, a startup power delay needs to be configured. In our tests we chose a delay of 15 seconds, but the delay could be decreased to 7-8 s, since the IP Box is only powered on, when the iPhone is running again.

The time required per passcode try largely depends on the time the iPhone takes to restart. We determined the startup times of the different devices as follows:

  • iPhone 4s: 48s
  • iPhone 5: 29s
  • iPhone 6: 27s

Brute-forcing a 4 digit passcode on an iOS 8 device will thus take between 3.5 and 6 days depending on the hardware.

The following video shows a successful passcode recovery on an iPhone 4s running iOS 8.1

Unlike iOS 7 where a phone can be disabled and the retrieval of the passcode is still possible, iOS 8 does no longer allow brute forcing the passcode on a disabled device. So make sure not to manually enter codes before unleashing the IP-Box on the iPhone.

Our tests lead to the conclusion that a 6 digit passcode already greatly improves the security of your iPhone. Running iOS 8 on a modern phone it would take about a year in the worst case to retrieve the passcode compared to the 3.5 days of the 4 digit code. If you are using a passcode with numbers and special characters while avoiding words from a dictionary or personal data such as the birth date, name, address or similar, it is currently virtually impossible to retrieve the passcode within a reasonable time frame.

This blog post resulted from internal research which has been conducted by Michael Fisler and Cyrill Bannwart in April 2015.

Hacklab Q2 – NoSQL mischief

At our reoccurring Hacklab days, we at Compass get the chance to hack some stuff of our own choice together for a day. For example playing with GSM in an attempt to send fake SMS or eavesdrop on voice data, comparing Encase capabilities to Unix command line forensic tools or cloning door entry badges in an attempt to gain unauthorized access to buildings or elevators.

During the Hacklab I gathered a few colleagues to create “team NoSQL” and toyed around with some of the example applications. Our project was based on a VM with several instances of “state of the art” web technologies, most of them involving a NoSQL database.

As a first task we performed a NoSQL injection on a self-developed PHP frontend with a MongoDB backend, as discussed in Hacking NodeJS and MongoDB. Additionally we wrote a python script which extracts cleartext password from the MongoDB with a binary search algorithm using the same vulnerability.

We also spent some time analyzing and exploiting race conditions in web applications, as for example described in Race Conditions on Facebook  and Hacking Starbucks for unlimited coffee. Using just the Linux command line, it was possible to generate arbitrary amount of money in a mockup Bitcoin website by sending a large amount of HTTP requests in parallel.

The slides of our presentation and the MongoDB bruteforcer script can be downloaded here:

Netzwerktraffic und APT Analyse

Compass Security wird vermehrt von Kunden bzgl. Verdacht auf Advanced Persistent Threat (APT) kontaktiert. Unter die Bezeichnung “APT” fallen komplexe, zielgerichtete und äusserst effektive Angriffe auf kritische und zuweilen gar unternehmenswichtige Computersysteme bzw. deren gespeicherte Informationen.
Die Analyse von potentiell infiltrierten Netzen und Systemen gestaltet sich jedoch als enorm aufwändig, da Unmengen von Datensätzen und Logs ausgewertet werden müssen. Compass hat deshalb immer wieder verschiedene Aspekte im Bereich APT, Forensik und Incident Response beleuchtet. Einerseits betreiben wir Research mit internen “Hack Labs” und “Research Weeks”, wo unsere Spezialisten sich mit den neusten Erkenntnissen der Scene auseinandersetzen bzw. diese weiter treiben und andererseits bearbeitet Compass in Zusammenarbeit mit den Security Fachabteilungen einer Vielzahl von Hochschulen, entsprechende Themen.

Eine entsprechend gewürdigte Maturaarbeit aus dem letzten Sommer möchten wir der Öffentlichkeit nicht länger vorenthalten und publizieren darum die Resultate im Rahmen dieses Posts. Im Mittelpunkt des Whitepapers steht die Analyse von APT mittels Splunk, einer spezialisierten Software zur Analyse von grossen Mengen maschinengenerierter Logdaten. Es werden darin auch alternative Wege zur Auswertung eruiert und ein Standardvorgehen für APT Fälle vorgeschlagen. Das Paper greift auch das bei Compass übliche Vorgehen bei forensischen Analysen auf und gibt dem technischen Leser in gewohnter Compass manier, viele technische Details mit auf den Weg. Natürlich auch einige Ideen, wie man das Logging von bestimmten Diensten optimieren könnte.

Möchten Sie gerne mehr zum Thema wissen? Möchten Sie auch erfahren, was dies in der Praxis bedeutet? Dann können wir Ihnen unser nächstes “Hands-on Seminar” mit dem Titel: Network Analysis & Advanced Persistent Threats vom 25. und 26. August 2015 in Bern empfehlen.

In der Zwischenzeit wünschen wir Ihnen viel Spass beim Schmökern. Behalten Sie einen kühlen Kopf compass_security_schweiz_whitepaper_apt_network_analysis_w_splunk_v1.1.pdf.

Compass Security Crew,
Cyrill Brunschwiler