Lifting the clouds from cloud investigations

Nettitude’s IR team recently had an opportunity to investigate a breach in a cloud environment. The client had recently adopted Office 365 in a hybrid configuration to host a range of Microsoft services for users, including email and SharePoint. They had seen very heavy traffic on their web application and traced the activity back to an admin user. They had seen that this user had requested a password change for the web application; the new credentials were sent to the users corporate email account, therefore the assumption was that the users corporate email account was compromised. Several other user accounts had also requested password resets in the web application around the same time as the suspect administrator account. We were asked to determine if the corporate accounts had been compromised and, if so, how.

Office 365

This was a good opportunity to investigate Office 365 installations. Some interesting discoveries were made, which will be shared in this post.

We discovered that Multi-Factor Authentication (MFA) was not enabled for the cloud environment. MFA is not enabled by default when Office 365 is deployed. In addition it is not possible to configure the lock-out policy for failed logon attempts beyond the default 10 failures.

We quickly developed a hypothesis that the impacted accounts had been brute forced. The client informed us that they had already eliminated this possibility from an analysis of the log files; there were no extensive incidents of failed logons in the time leading up to the suspected compromise. We therefore requested access to the audit logs in Office 365 in order to validate their findings. The audit log interface can be found in the Security & Compliance Centre component of the web interface.

Anyone who has had to do a live analysis of Office 365 will know that it can be a frustrating experience. The investigator is presented with a limited web interface and must configure their search criteria in that interface. Results are presented in batches of 150 logs; to view the next 150 results the investigator must pull down a slider in the web interface and wait, often for minutes, before the results are presented. You then repeat this process in order to view the next batch of 150 logs, and so on.

You will find that analysis is much quicker if you use the “export” feature to export all of the filtered audit logs to a spreadsheet. However, this will present the investigator with a new set of challenges. Firstly, you should understand that auditing, when enabled, will log a vast array of user operations, many of which will not be relevant to the investigation. Secondly, the exported logs are not very user friendly at all. Each record consists of 4 fields:

  • CreationDate
  • UserID
  • Operations
  • AuditData

There are a vast array of key-value pairs, many of which are concatenated into a single field named AuditData. Thus an example of a single record might look something like this (much of the data has been edited to obscure traceable indicators)

The structure is not static across all records; the contents of the AuditData field will change depending what user operation has been performed. Therefore there will be a varying number of key-pair fields present which makes writing a parser challenging. Fortunately, Microsoft have published both the detailed audit properties and the Office 365 management activity API schema that we can use to understand the data in the audit logs.

Log Analysis

In the absence of an existing parser, we had a requirement to quickly process these logs so that the data could be analysed and presented in an understandable format. Realising that the data was structured, albeit with variable numbers of key-value pairs, we turned to our Swiss army knife for structured data – Microsoft Log Parser and Log Parser Studio front end.

For those not familiar with this tool, it is produced by Microsoft and allows a user to execute SQL-like queries against structured data to extract fields of interest from that data. We have previously published some LogParser queries to process sysmon event logs.

We wrote some quick and dirty queries to process exported Office 365 audit data. They are by no means comprehensive, but they should be sufficient to get you started if you need to analyse Office 365 audit log data. We are therefore publishing them for the wider community in our Github repository.

Below is an example of the LogParser query that we wrote to extract Failed Logon operations from the audit logs:

Analysis Results

Our initial analysis of the audit data matched the client’s findings; there was very little indication of failed logons to the impacted accounts prior to the suspected breach. However, our initial analysis was “vertical”; that is to say that it cussed on a single user account suspected of being compromised. We know from the daily investigations that we perform for our clients using our SOC managed service, that you don’t get the full picture unless you do both a vertical AND horizontal analysis. A horizontal analysis is one that encompasses all user accounts across a particular time-frame – normally one that includes the suspected time of a compromise.

We therefore re-oriented our investigation to perform a horizontal analysis. We exported all of the Office 365 audit data for all operations on all user accounts across a 30 minute time frame in the early hours of the morning of the suspected breach, when you would expect very little user activity. Our first finding was that there was significant volume of activity in the logs encompassing every single user account in the client’s estate. Once we applied our LogParser queries to the log data, it immediately became clear how the attack had occurred and succeeded. The data now showed the unmistakable fingerprint of a password spraying attack.

Password Spraying

Password spraying is a variation on traditional brute force attacks. A traditional brute force is directed against a single user account; a dictionary of potential passwords are attempted in sequence until the correct one is found or the dictionary is exhausted, in which case the attacker will configure a new account name to attack, then launch the dictionary attack on that account. However, an entry in a log file may be recorded for each failed attempt, so any organisation monitoring logs for failed attempts could detect this attack. In addition, the way to defend your organisation against such attacks is to configure a lock-out threshold on each user account, so that no further attempts to authenticate are permitted after a pre-configured number of failed attempts within a specified time frame.

Password spraying is a technique used by attackers to circumvent the previously described controls. Instead of attacking a single user account, the technique involves attacking a large number of accounts but with a potentially smaller dictionary. So if an attacker has a list of 300 user accounts and a dictionary of 2 passwords, the sequence of the attack would be:

  • UserAcct1: Password1
  • UserAcct2: Password1
  • UserAcct3: Password1
  • <snip>
  • UserAcct300:Password1
  • UserAcct1: Password2
  • UserAcct2: Password2
  • UserAcct3: Password2
  • <etc>

If the attacker is smart, they will throttle the attack in order to avoid any potential lock-out time thresholds. By the time the second password attempt is attempted on any particular account, hopefully (from the attacker’s point of view), the account will have moved outside of the lock-out threshold time frame. That is what happened in our investigation; the attacker had a list of over 1000 user accounts and was throttling their attack so that although they were trying one username/password combination per second, any particular user account was only subjected to about 2 password guesses per hour. This illustrates the value of conducting both horizontal and vertical analysis.

Analysis Conclusions

Our analysis concluded that 12 accounts had been successfully compromised during the password spraying attack. The indications were that the attacker only needed a dictionary of 100 potential passwords (or less) to compromise those 12 accounts. The average number of password guesses across the compromised accounts was around 60 before compromise, while the least amount of guesses required to compromise an account was 16. It was determined that the attack had been ongoing for over 24 hours before any component of the attack was detected.

It was determined that the client was using a password policy of a minimum of 8 character passwords, which is the default password policy for Office 365.

Investigation Curiosities

It was noted, during the investigation of the Office 365 logs, that the logs were inconsistent in terms of recording successful logons. We found analysis of the logs from the Clients AzureAD installation gave a much higher-fidelity view of successful logons.

There were also anomalies in the time stamps of some of the operations recorded in the Office 365 audit logs. We determined that users were spread over a number of different time zones and concluded that they had failed to configure the correct time zone when they first logged in to their Office 365 accounts. This can have a significant negative impact on the accuracy of the audit logs in Office 365 – we therefore advise all investigators to be cognisant of this issue.

The attacker appeared to have a very accurate and comprehensive list of valid user accounts relevant to the target organisation. We concluded that that this was obtained during a previous compromise of a user account within the organisation wherein the attacker downloaded the Global Address Book from the compromised account.


To summarise, the takeaways from this investigation:

  • Ensure MFA is enabled on your O365 installation.
  • Educate your users about password security.
  • Watch your logs; consider implementing a SIEM solution.
  • Export the logs from both O365 and Azure AD during an investigation.
  • Conduct a horizontal and vertical analysis of user logs for most accurate results.
  • Ensure that all users configure their correct time zone when they first log in to Office365.

CVE-2017-8116: Teltonika router unauthenticated remote code execution

We sometimes require internet connectivity in situations where a traditional connection is not easily possible. 4G routers provide an answer to this problem by providing connectivity to a variety of devices and systems without the need for a fixed internet connection.  They typically have one thing in common – a web based management interface. Read more

BSides Edinburgh 2017 Crypto Contest Write Up

Recently, at the inaugural BSides Edinburgh, Ben Turner and I made the trek up to Edinburgh to see our colleague Neil Lines present his talk “The Hunt for The Red DA”. I can’t say that I am a massive fan of such early starts (we jumped on the first flight out of Birmingham), but thankfully the organisers made the trip absolutely worth it. The talks that I saw were well presented and had good technical content while the venue was absolutely amazing. I even learnt some stuff about the world of IoT that I wished I didn’t know; cheers Ken.

The conference was very well supported by the sponsors, particularly with the solid training on offer. We even recognised the faces of some of the competition from the CTF at DerbyCon. We’re really looking forward to doing battle again later in the year…

The crypto contest

SecureWorks kindly created a challenge for the BSides Edinburgh 2017 audience; they named it the Crypto Contest. Personally, I think one of the core skills as a good penetration tester is being able to quickly deal with data that are you are unfamiliar with and to have a good set of tools that can parse & process in a flexible way. The contest was a good way to practice some of those skills and demonstrate to my colleagues why pure C# in the world’s best programming tool – LINQPad is better than Powershell 😉 Plus, there were some very cool prizes on hand; our eyes quickly zoned in on the Hak5 Bash Bunny.

Challenge number 1 – Square

Navigating to, we got the following wall of text

Now credit for this goes to Ben; after trying some advanced military grade cryptographic techniques such as ROT13, he craned his neck and quickly spotted that this was in fact just rotated text. Yep, I was massively over thinking it too! All we had to do was quickly put together some code that would rotate the text 90 degrees around the origin. Firing up LINQPad, the following solution was created (which of course has been tidied up and comments added).

The following out is produced and the flag is ours:

Sure, we could have put the monitor on its side, but where’s the fun in that?

Challenge 2 – Royale

Opening the page, you got the following, which was immediately recognisable as Morse code. The instructions stated you need to “Please decode the following message, adding appropriate spacing as needed so the flag is readable.”

Funnily enough, I had never worked with Morse code before, but the first thing I noticed was that thankfully Secureworks had put in spaces between prosigns, which made the code a little easier. The first step was to obtain a Morse code library, one that would translate the symbols to letters. This was pretty easy to find with Google and allowed me to build up a CSV file which looked something like this:

Once again, using LINQPad, the following code split up all the symbols, translate each one and then coverted it all into a string.

This gave us the following result, which is written in the NATO phonetic alphabet.

So, a slight tweak to the code, changing the last line to:

…and the next flag was ours:

Challenge 3 – Royale.txt

For challenge 3,, we received the instructions “Decipher the message from this transmission” and then the following:

The first calculation was the size; the 5 lines contained 1200 bits (150 bytes). Assuming bytes was our first mistake; this had us trying to convert to different text forms and every kind of data type that we could think of, without any luck. Being bits, we then tried creating images types, e.g. bitmap and even QR codes (which in fairness didn’t really align to the size). The path then led to 6 bit characters because, well, 1200 divides by that very nicely. In honesty, we should have looked more into that first, but we didn’t as there was a talk we wanted to see (honest :)).

So, we were back inside the vendor area when the following tweet arrived.

Feel it out… hang on… Braille uses 6 bit characters, right? Bingo! Straight to to look at the Braille glyphs:

The 2×3 column structure lined up very nicely with the text in the transmission. Cool, so time to bash some code out. By this stage, you can probably guess what tool was opened up 🙂

The first step was to once again create a dictionary file that would translate the glyphs to ASCII. For this, we borrowed the text from the wiki page and built a csv file translating the positions into a letter. It looked like this:

Next was to write some code that translated those positions into characters. We bashed out the following quickly (it’s not perfect but did the job):

We get the following output; there were a couple of manual corrections that we needed to make to get the flag, but it looked like the Bash Bunny might be ours.

Yeah, it was!


While not a Crypto contest in the strictest sense of the word, it was still a lot of fun and we got some practice with data formats that we don’t normally come across. As I said at the start, this is an important skill. A big thank you to SecureWorks for putting the time in to create this contest – we really enjoyed it and we hope you all enjoyed our write up!

– Rob, Ben & Neil

A quick analysis of the latest Shadow Brokers dump

Just in time for Easter, the Shadow Brokers released the latest installment of an NSA data dump, which contained an almost overwhelming amount of content – including, amongst other things, a number of Windows exploits. We thought we’d run some quick analysis on various elements of said content.

Before we get started

We’re going to largely avoid the obvious elements of the dump because there’s already been a lot of very helpful analysis of those elements. However, before we get to that, here’s what you need to know:

  • Patch!  The majority of the high impact Microsoft vulnerabilities have recently been addressed in the MS17-010 patch.
  • Disable SMBv1.
  • Remove all Windows XP and 2003 machines from your network.  These contain vulnerabilities that will not be patched.

The following table (raw data available at and courtesy of @etlow) contains some of the more pertinent information.

Shadow Brokers Exploit Table

Shadow Brokers Exploit Table

We can also recommend the following script by Luke Jennings, which is designed to sweep a network to find Windows systems compromised with the dumps DOUBLEPULSAR implant:

With that out of the way…

Metadata, or a lack of

Throughout the Equation Group leak via the Shadow Brokers, there are a number of different languages being used. One interesting element is how it appears that there was originally a preference for Perl, that was then replaced with Python – we think that this mirrors how the offensive security industry has evolved, too.

As the age of the dump is pinned at some point in 2013, we would have expected to see a little bit of PowerShell; this was really starting to come into favor around that time. Now, this post isn’t about dropping a new l33t PowerShell technique gained from the dump, but rather looking at what the capability was at the point in time. Staying with the timing of the dump for a minute, we are reminded of the following series of Tweets from Edward Snowden back in August last year, when the ShadowBrokers [6] first dropped.

We know we run the risk of taking these out of context, and it is entirely possible that his mind has been changed since, however we find the following piece of information interesting. According to the time line from the Guardian [5], the first release of the material he took was on the 5th June 2013. It’s probable that other dumps have since has contradicted this and the view of when the hacker/s were kicked off has been able to be narrowed, but we am unaware of this (so please if you know different answers on a postcard).

Examining of the tools makedmgd.exe, part of a toolkit DAMAGEDGOODS that is used within in a PowerShell delivery framework ZIPO we see the following. One of the first things that we noticed is that yeah hmmm the build date is baked into the exe. Also some different implants not within the dump are there “distantuncle” and “finkdiffernt”; some of the coders definitely have a certain sense of humor.

Using Sysinternals excellent sigcheck.exe [7] we could view the publisher, version and build date in order to correlate. Yes, it is one of the many ways to list a binarys metadata, but some of its other superb features are that, as the name implies, it will verify the signature if the binary has been signed using Authenticode and it is also able to send the binary straight to VirusTotal and look at all files within a directory tree recursively. Running sigcheck, unsurprisingly we get the following information or, some would say, a lack of.

Any trace of publisher or company which, to be fair, will be set in Visual Studio (or your toolchain of choice have either been stripped or not set). The Link date is there, which correlates to the build date, which is also five weeks after Snowden’s material was first dropped. It is entirely possible to mess with and edit these dates, of course, before releasing the dump. We do find it strange to go the level of stripping all other information but hard coding a build date, particularly in a tool that will be released to a workstation. The directory structure that this is in implies it may have been copied in rather than part of a release, as it was new and may not have been sanitised properly (although there is a real danger of reading too much into it).

First steps into PowerShell

As stated above, we would have expected to see a reasonable amount of PowerShell considering the year, but actually there is very little. The only real example that we have found is a tool called ZiPo which can be found within the dump at /Resources/Ops/Tools/ZiPo. It contains the following tools

  • decryptor_downloader.base
  • makedmgd.exe
  • ps_base.txt

In order to run this tool we call, which first asks you to select a “project” directory then presents a menu asking if we want to:

  1. Upload / Create Execute an Egg
  2. Upload/ Create PowerShell script
  3. Create Compressed script to be run manually

Now Egg is a term that is used quite heavily throughout the dump and we’re not entirely sure what it means at this point in time. Pretty sure it is an Equation Group term.

Choosing PowerShell script we are then asking for the location of it, what the IP address and port of the “redirector” which we assume is a proxy and then the local IP address and proxy. This is so that the script can spin up a HTTPd listener to serve up the files that have been created.

In order to test, we created a very simple PowerShell script containing:

It has generated a public/private key pair, created an index.html & index.htm, provided us with a script to run on the target and also started up a HTTPd so that we could download the payloads on the target. That’s not too bad for a couple of commands.

Looking at the command to run its pretty standard PowerShell from the time, in fact we find it really interesting there is absolutely no attempt at obfuscating anything here. They are encrypting the payload and building a chain to download/decrypt etc, but no effort is made at hiding what the command is doing or where it is obtaining the script from (of course we would be very interested to see what they are doing now).

So what is contained within the two index files? Well, index.html is base64 PowerShell script, which is why it was executed as an encodedCommand; decoding you get the output below. It encrypts a known “questionable” password value using RSA, another WebClient is created which has the encrypted value set as a cookie. The index.html is then downloaded and decrypted using the key, which is a SHA1 hash of the “questionable value”. The payload is then executed and on the server the two files are then deleted. This is a lot of effort to hide the final payload and once again absolutely no effort to obfuscate any of the script.

This is how it looks when it is run:


The next thing that we did was to just create a meterpreter payload; nothing special and wasn’t going to get to connect back, but we felt that AV should still be able to pick it up.

Running Zipo again, we selected the third option. It asks you for a payload DLL and also the ordinal [8] that you want to fire. This is where DAMAGEDGOODS comes into play; makedmged.exe is the exe that appears to do some kind of shellcode encoding. In this case it takes the encoded binary with a script called ps_base.txt, then compresses/base64 encodes and then builds a decompression payload around it.

The script that is output at the end of this using the name you supplied is the decode/decompression/execute mentioned above and is shown below.

Decoding it you get the following, which is quite interesting; it’s a PowerShell script that allocates memory, writes the shellcode into it, creates a thread and then executes the shellcode, all in memory. The shellcode in this case is going to be the meterpreter DLL that we originally used. Running it multiple times over the same DLL you get a different version. There appears to be some kind of prologue in the shellcode that doesn’t change, but it is pretty short, running the script multiple times and then diffing with Scooter Software’s excellent Beyond Compare you find that the only section that has changed is the shellcode except for:

This series of bytes which appears to be some kind of prologue probably a decoder for the rest of the shellcode. What does it do, how does it work? Well that, we’re afraid, is for part 2 as we’ve spent too much time away from the family already this easter ;o)


This kinda looks familiar….

Now the great irony in a dump like this is finding code that appears to have come from GitHub but doesn’t appear to have the same licence or any at all for that matter [1]. This script is built from file called ps_base.txt. This is primarily used to dynamically build a type that will eventually hold a function pointer to a native function. This is then used to store the fp’s for native functions Win32 functions such as VirtualAlloc[2], GetProcessAddress[3] & GetModuleHandle[4] that can be used to perform some actions such as allocating memory and looking up the addresses of exports within DLL’s. Further are shown in this screen shot:

Now the method to create the delegate’s used in the above code is:

Programmers (ourselves included) can be utter sticklers for formatting, so it is conspicuous that there is such a big difference in formatting between the code in ps_base.txt vs decryptor_downloader.base. It’s almost as if ps_base.txt has come from somewhere else.

Well funnily enough it bears more than just a striking resemblance to some code from Powersploit[1]; screenshots from GitHub are below. Surprisingly not too much effort has been made to change the method names.

And also…

The commit date for this code is…

And as stated above we have a built date of July 2013; does this mean we will find StackOverflow answer code within the dump at some point?

But anyway back to makedmg.exe running it we get this list of other implants that are not in this dump; obviously still a lot out there.


From analysis we did on some implant configuration files, Darkpulsar appears to create a service called ‘dapu’ It also seems that when it upgrades itself it drops the new file using the following path: ‘c:\windows\system32\sipauth32.tsp’.

We also had a look at tdip.sys driver.

(sha256: A5EC4D102D802ADA7C5083AF53FD9D3C9B5AA83BE9DE58DBB4FAC7876FAF6D29)

We found same magic DWORDs as those mentioned by Kaspersky Labs in the following link: which contains information from a previous ‘ShadowBrokers’ dump.

The following code snippet is taken from tdip.sys:

This driver was most probably used to capture network traffic and it also accepts IOCTLs from userland. There is probably a relation between this driver and “TrafficCapture_Target.dll” module that we found inside the recent ShadowBrokers dump, which we noticed that it is able to communicate with a kernel driver via IOCTLs.


Keeping in mind that this is a subset of the techniques that the Equation Group had in 2013, we still find it pretty interesting that just like the rest of the world they were starting to wake up to the potential of offensive PowerShell. The lack of any obfuscation i.e attempt to hide any of the decryption/download code was another surprise too considering how much “effort” has gone into encrypting the payload over the network at that point. The source of some of the code is intriguing, too.

But back to the initial thoughts, we probably can be sure that this code was from 2013. Is it possible that Ed’s assertion the “hacker squatting lost access in June” may be flawed and they had access until at least the first couple of weeks in July. Assuming SB and no one else has tampered with the metadata within DAMAGEDGOODS, then yes.