Category Archives: Intrusion Analysis

Evolution of Stack Based Buffer Overflows

overflowOn the 2nd November, 1988 the Morris Worm was the first blended threat affecting multiple systems on the Internet.  One of the things the worm did was to exploit a buffer overflow against the fingerd daemon due to the usage of gets() library function. In this particular case the fingerd program had a 512-byte buffer for gets(). However, this function would not verify if the input received was bigger than the allocated buffer i.e., would not perform boundary checking. Due to this, Morris was able to craft an exploit of 536-bytes which will fill the gets() buffer and overwrite parts of the stack. More precisely it overwrote the memory address of the return stack frame with a new address. This new address would point into the stack where the crafted input has been stored. The shellcode consisted on a series of opcodes that would perform the execve(“/bin/sh”,0,0) system call. This would give a shell prompt to the attacker. A detailed analysis about it was written by the Eugene Spafford, an American professor of computer science at Purdue University. This was a big event and made buffer overflows gain notoriety.

Time has passed and the security community had to wait for information about the closely guarded technique to be publicly available.  One of the first articles on how to exploit buffer overflows was written in the fall of 1995 by Peiter Zatko a.k.a Mudge – at the time Mudge was one of the members of the prominent hacker group L0pht.  One year later, in the summer of 1996, the 49th issue of the Phrack e-zine was published. With it, came the notorious step-by-step article “Smashing the Stack for Fun and Profit” written by Elias Levy a.k.a. Aleph1.  This article is still today a reference for the academia and for the industry in order to understand buffer overflows.  In addition to these two articles another one was written in 1997 by Nathan Smith named ” Stack Smashing vulnerabilities in the UNIX Operating System.” These 3 articles, especially the article from Aleph1 allowed the security community to learn and understand the techniques needed to perform such attacks.

Meanwhile, in April 1997 Alexander Peslyak a.k.a. Solar Designer posted on Bugtraq mailling list a Linux patch in order to defeat this kind of attacks. His work consisted in changing the memory permissions of the stack to read and write instead of read, write and execute. This would defeat buffer overflows where the malicious code would reside in the stack and would need to be executed from there.

Nonetheless, Alexander went further and in August 1997 he was the first to demonstrate how to get around a non-executable stack using a technique known as return-to-libc. Essentially, when executing a buffer overflow the limits of the original buffer will be exceeded by the malicious input and the adjacent memory will be overwritten, especially the return stack frame address. The return stack frame address is overwritten with a new address. This new address, instead of pointing to an address on the stack it will point to a memory address occupied by the libc library e.g, system().  Libc is the C library that contains all the system functions on Linux such as printf(), system() and exit().  This is an ingenious technique which bypasses non-executable stack and doesn’t need shellcode.  This technique can be achieved in three steps. As Linus Torvalds wrote in 1998 you do something like this:

  • Overflow the buffer on the stack, so that the return value is overwritten by a pointer to the “system()” library function.
  • The next four bytes are crap (a “return pointer” for the system call, which you don’t care about)
  • The next four bytes are a pointer to some random place in the shared library again that contains the string “/bin/sh” (and yes, just do a strings on the thing and you’ll find it).

Apart of pioneering the demonstration of this technique, Alexander also improved his previous non-executable stack patch with a technique called ASCII Armoring. ASCII Armoring would make buffer overflows more difficult to happen because it will map the shared libraries on memory address that contain a zero byte such as 0xb7e39d00.  This was another clever defense because one of the causes of buffer overflows is the way the C language handles string routines like strcp(), gets() and many others. These routines are created to handle strings that terminate with a null byte i.e, a NULL character. So, you as an attacker when you are crafting your malicious payload you could provide malicious input that does not contain NULL character. This will be processed by the string handling routine with catastrophic consequences because it does not know where to stop.  By introducing this null byte into memory addresses the payload of buffer overflows that are processed by the string handling routines will break.

Based on the work from Alexander Peslyak, Rafal Wojtczuk a.k.a. Nergal, wrote in January 1998 to the Bugtraq mailing list another way to perform return-to-libc attacks in order to defeat the non-executable stack. This new technique presented a method that was not confined to return to system() libc  and could use other functions such as strcpy() and chain them together.

Meanwhile, In October 1999, Taeh Oh wrote “Advanced Buffer Overflow Exploits” describing novel techniques to create shellcode that could be used to exploit buffer overflow attack.

Following all this activity, Crispin Cowan presented on the 7th USENIX Security Symposium on January 1998 a technology known as StackGuard. StackGuard was a compiler extension that introduced the concept of “canaries”. In order to prevent buffer overflows, binaries compiled with this technology will have a special value that is created during the function epilogue and pushed into the stack next to the address of the return stack frame. This special value is referred as the canary. When preforming the prologue of a function call, StackGuard will check if the address of the return stack frame has been preserved. In case the address has been altered the execution of the program will be terminated.

As always in the never ending cat and mice game of the security industry, after this new security technique was introduced, others have had to innovate and take it to the next level in order to circumvent the implemented measures.  The first information about bypassing the StackGuard was discovered in November 1999 by the Polish hacker Mariusz Wołoszyn and posted on the BugTraq mailing list. Following that In January 2000, Mariuz a.k.a. Kil3r and Bulba, published on Phrack 56 the article “Bypassing StackGuard and StackShield”.  Following that a step forward was made in 2002 by Gerardo Richarte from CORE security who wrote the paper “Four different tricks to bypass StackShield and StackGuard protection”.

The non-executable stack patch developed by Alexander was not adopted by all Linux distributions and the industry had to until the year 2000 for something to be adopted more widely.  In August 2000, the PaX team (now part of GR-security) released a protection mechanism known as Page-eXec (PaX) that would make some areas of the process address space not executable i.e., the stack and the heap by changing the way memory paging is done.  This mitigation technique is nowadays standard in the GNU Compiler Collection (GCC) and can be turned off with the flag “-z execstack”.

Then in 2001, the PaX team implemented and released another mechanism known as Address Space Layout Randomization (ASLR). This method defeats the predictability of addresses in virtual memory. ASLR randomly arranges the virtual memory layout for a process. With this the addresses of shared libraries and the location of the stack and heap are randomized. This will make return-to-libc attacks more difficult because the address of the C libraries such as system() cannot be determined in advance.

By 2001, the Linux Kernel had two measures to protect against unwarranted code execution. The non-executable stack and ASLR. Nonetheless, Mariusz Wołoszyn wrote a breakthrough paper in issue 58 of Phrack on December 2001.  The article was called “The Advanced return-into-lib(c) exploits” and basically introduced a new techniques known as return-to-plt. This technique was able to defeat the first ASLR implementation. Then the PaX team strengthen the ASLR implementation and introduced a new feature to defend against return-to-plt. As expected this technique didn’t last long without a comprehensive study on how to bypass it. It was August 2002 and Tyler Durden published an article on Phrack issue 59 titled “Bypassing PaX ASLR protection”.

Today, ASLR is adopted by many Linux distributions. Nowadays is built into the Linux Kernel and on Debian and Ubuntu based systems is controlled by the parameter  /proc/sys/kernel/randomize_va_space. This mitigation can be changed with the command “echo <value > /proc/sys/kernel/randomize_va_space ” where value can be:

  • 0 – Disable ASLR. This setting is applied if the kernel is booted with the norandmaps boot parameter.
  • 1 – Randomize the positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions. The base address of the data segment is located immediately after the end of the executable code segment.
  • 2 – Randomize the positions of the stack, VDSO page, shared memory regions, and the data segment. This is the default setting.

Interesting is the fact that on 32-bit Linux machines an attacker with local access could disable ASLR just by running the command “ulimit -c”. A patch has just been released to fix this weakness.

Following the work of StackGuard, the IBM researcher Hiroaki Etoh developed ProPolice in 2000. ProPolice is known today as Stack Smashing Protection (SSP) and was created based on the StackGuard foundations. However, it brought new techniques like protecting not only the return stack frame address as StackGuard did but also protecting the frame pointer and a new way to generate the canary values. Nowadays this feature is standard in the GNU Compiler Collection (GCC) and can be turned on with the flag “-fstack-protector”.  Ben Hawkes in 2006 presented at Ruxcoon a technique to bypass the ProPolice/SSP stack canaries using brute force methods to find the canary value.

Time passed and in 2004, Jakub Jelinek from RedHat introduced a new technique known as RELRO. This mitigation technique was implemented in order to harden data sections of ELF binaries.  ELF internal data sections will be reordered. In case of a buffer overflow in the .data or .bss section the attacker will not be able to use the GOT-overwrite attack because the entire Global Offset Table is (re)mapped as read only which will avoid format strings and 4-byte write attacks. Today this feature is standard in GCC and comes in two flavours. Partial RELRO (-z relro) and Full RELRO (-z relro -z now). More recently, Chris Rohlf wrote an article about it here and Tobias Klein wrote about it on a blog post.

Also in 2004 a new mitigation technique was introduced by RedHat engineers. The technique is known as Position Independent Executable (PIE). PIE is ASLR but for ELF binaries. ASLR works at the Kernel level and makes sure shared libraries and memory segments are arranged in randomized addresses. However, binaries don’t have this property. This means the addresses of the compiled binary when loaded into memory are not randomized and become a weak spot for protection against buffer overflows. To mitigate this weakness, RedHat introduced the PIE flag in GCC (-pie). Binaries that have been compiled with this flag will be loaded at random addresses.

The combination of RELRO, ASLR, PIE and Non-executable stack raised significantly the bar in protecting against buffer overflows using return-to-libc technique and its variants. However, this didn’t last long. First Sebastian Krahmer from SUSE developed a new variant of return-to-libc attack for x64 systems. Sebastian wrote a paper called “x86-64 buffer overflows exploits and the borrowed code chunks exploitation technique”.

Then with an innovative paper published on ACM in 2007, Hovav Shacham wrote “The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)”. Hovav introduced the concept of using return oriented programming and what he called gadgets to extend the return-to-libc technique and bypass different mitigation’s enforced by the Linux operating system. This technique was based on the work from Solar and Nergal and does not need to inject code and takes advantage of existing instructions from the binary itself. Reuse existing instructions and chain them together using the RET instruction to achieve the end goal of manipulating the program control flow execute code of attackers choice. This is a difficult technique to perform but is powerful and is known as ROP. A summary was  presented by Hovav on Black Hat 2008.

Also, in 2008, Tilo Müller wrote “ASLR Smack & Laugh Reference” explaining the different attacks against ASLR in a comprehensive study that outlines the various techniques. In 2009 the paper “Surgically returning to randomized lib(c)” from Giampaolo Fresi Roglia also explains how to bypass non-executable stack and ASLR.

In 2010, Black Hat had 3 talks about Return-Oriented exploitation. More recently and to facilitate ROP exploitation, the French security researcher Jonathan Salwan wrote a tool written in Python called ROPgadget. This tool supports many CPU architectures and allows the attacker to find the different gadgets needed to build its ROP chain. Jonathan is also gives lectures and makes his material accessible. Here is the 2014 course lecture on Return Oriented Programming and ROP chain generation. ROP is the current attack method of choice for exploitation and research is ongoing on mitigation and further evolution.

Hopefully, this is gives you good reference material and a good overview about the evolution of the different attacks and mechanisms against  Stack based buffer overflows. There are other type of buffer overflows like format strings, integer overflows and heap based but those are more complex. Buffer Overflows is a good starting point before understanding those. Apart of all the material linked in this article, good resources for learning about this topic are the books Hacking: The Art of Exploitation by Jon Erickson, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes by Chris Anley, and A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security by Tobias Klein.


Tagged , , , , , ,

Exploit Kit Turf Wars

A rare event when two different Exploit Kits are disputing victims’ over the same territory. The threat actors behind the EK’s are finding vulnerable websites in order to host their malicious JavaScript code globally in a repeatable and automated fashion [13][14]. By a twist of fate a legitimate web server was turned into a mechanism to deliver malicious code by two of the most popular EK’s. An unfortunate but remarkable event where one can observe the confrontation between the challenger Neutrino Exploit Kit [10][11] and the infamous Angler Exploit Kit [2][3][7] in a fierce competition.

Once a user visits the compromised site the user is redirected to both the Neutrino and Angler EK landing pages. Both exploit kits enforce sophisticated capabilities that evade detection, thwart analysis and deliver reliable exploits [19]. First, the client IP address is profiled in order to filter out systems that do not meet the requirements. Then it follows a series of events with the goal to find un-patched browsers and applications that permit the EK to exploit client side vulnerabilities to deliver a malicious payload. On one hand the Neutrino facilitates the delivery of the Locky ransomware. On the other hand Angler facilitates the delivery of the TeslaCrypt ransomware.

Both EK’s follow the same strategy – Deliver malicious Adobe Flash files that act as facilitator to carry different exploits.  In this particular case, Neutrino is the first to be executed. When the user gets redirected to the landing page a small HTML page with an object tag defined in its body is delivered. This object tag directs the browser to load the first stage Flash file [1]. The first stage Flash file is then loaded and a decryption routine occurs at runtime that loads another Flash file. This file is used as wrapper for the multiple exploits and contains ActionScript3 code that verifies if the properties of the system environment are the right ones. The below picture shows the decompiled ActionScript3 code of the second stage Flash file. On the right side the different environmental checks performed by code.


If the conditions are met then the environment is fingerprinted in order to determine which vulnerability to exploit. On the left side of the above picture you can see the different wrappers that contains 5 different exploits. Then is a matter of code execution. In the below picture we can see Neutrino exploiting CVE-2015-0016 and invoking wscript.exe to download an encrypted payload which in this case is the new ransomware called Locky [16][17].


Meanwhile, Angler delivers obfuscated JavaScript code combined with HTML tags that is blended with the main page of the compromised site. After several layers of obfuscation the result is a JavaScript function that stores a cookie and makes the browser process a HTML <iframe> tag. This triggers the browser to make a request to the Angler landing page which has a remarkable thumbprint. Among the malicious and heavily obfuscated JavaScript code you have passages from Jane Austen’s Sense and Sensibility book [8][12]. The picture below shows these passages in the traffic stream.


Following that, the malicious code verifies the presence of different antivirus and virtualization software [17]. If any of the checks perform return positive then the code will stop the infection process. If that is not the case a malicious Adobe Flash file is downloaded. Just like Neutrino, the malicious Adobe Flash file acts as a facilitator. The first stage Flash file is loaded and a decryption routine occurs at runtime that loads another Flash file. This file is used as wrapper for the multiple exploits that Angler supports [4][5][18][20]. If the victim system is vulnerable then the exploit code is executed and shellcode will instruct the operating system to download the malware in an encrypted fashion. The payload is then, decrypted and launched [6][9]. Angler has the particularity to allow fileless infections which means the malicious code is never written to disk and stays in memory. This makes it difficult to detect and analyse. When the malicious payload is launched the victim will be promted with UAC dialog box if does not have admin rights asking for the Administrator password. If the password is entered, the executable is launched and the system gets infected with TeslaCrypt.

In this head to head battle for resources and against the infamous Angler, Neutrino seems to be faster and wins! As illustrated in the below picture when Angler is prompting the user for admin credentials Neutrino already infected the system and display the new locky ransom note (see behind the UAC prompt).


For security enthusiasts, I uploaded the ExploitKitTurfWars.pcap file to Virus Total. This will allow one to practice and improve their ability to determine the actions which have taken place and understand all kinds of artifacts which occur within this interesting scenario. Might be interesting to find why in this case Neutrino is more effective. Practice these kind of skills and share your experiences!

Against these sophisticated threats there is no silver bullet. General mitigations against malware threats are provided by US-CERT here. Because Exploit Kits rely heavily on client side exploits, it is important to keep browsers, operating systems and applications updated. In addition, for home users the usage of Microsoft EMET and non-admin account is a must.





Tagged , , ,

Unleashing YARA – Part 1

[Editor’s Note: In the article below, Ricardo Dias who is a SANS GCFA gold certified and a seasoned security professional demonstrates the usefulness of Yara – the Swiss Army knife for Incident Responders. This way you can get familiar with this versatile tool and develop more proactive and mature response practices against threats. ~Luis]


yara_logoI remember back in 2011 when I’ve first used YARA. I was working as a security analyst on an incident response (IR) team, doing a lot of intrusion detection, forensics and malware analysis. YARA joined the tool set of the team with the purpose to enhance preliminary malware static analysis of portable executable (PE) files. Details from the PE header, imports and strings derived from the analysis resulted in YARA rules and shared within the team. It was considerably faster to check new malware samples against the rule repository when compared to lookup analysis reports. Back then concepts like the kill chain, indicator of compromise (IOC) and threat intelligence where still at its dawn.

In short YARA is an open-source tool capable of searching for strings inside files (1). The tool features a small but powerful command line scanning engine, written in pure C, optimized for speed. The engine is multi-platform, running on Windows, Linux and MacOS X. The tool also features a Python extension providing access to the engine via python scripts. Last but not least the engine is also capable of scanning running processes. YARA rules resemble C code, generally composed of two sections: the strings definition and a, mandatory, boolean expression (condition). Rules can be expressed as shown:

rule evil_executable
        $ascii_01 = "mozart.pdb"
        $byte_01  = { 44 65 6d 6f 63 72 61 63 79 }
        uint16(0) == 0x5A4D and
        1 of ( $ascii_01, $byte_01 )

The lexical simplicity of a rule and its boolean logic makes it a perfect IOC. In fact ever since 2011 the number of security vendors supporting YARA rules is increasing, meaning that the tool is no longer limited to the analyst laptop. It is now featured in malware sandboxes, honey-clients, forensic tools and network security appliances (2). Moreover, with the growing security community adopting YARA format to share IOCs, one can easily foresee a wider adoption of the format in the cyber defence arena.

In the meantime YARA became a feature rich scanner, particularly with the integration of modules. In essence modules enable very fine grained scanning while maintaining the rule readability. For example the PE module, specially crafted for handling Windows executable files, one can create a rule that will match a given PE section name. Similarly, the Hash module allows the creation on hashes (i.e. MD5) based on portions of a file, say for example a section of a PE file.

YARA in the incident response team

So how does exactly a tool like YARA integrate in the incident response team? Perhaps the most obvious answer is to develop and use YARA rules when performing malware static analysis, after all this is when the binary file is dissected, disassembled and understood. This gives you the chance to cross-reference the sample with previous analysis, thus saving time in case of a positive match, and creating new rules with the details extracted from the analysis. While there is nothing wrong with this approach, it is still focused on a very specific stage of the incident response. Moreover, if you don’t perform malware analysis you might end up opting to rule out YARA from your tool set.

Lets look at the SPAM analysis use case. If your team analyses suspicious email messages as part of their IR process, there is great chance for you to stumble across documents featuring malicious macros or websites redirecting to exploit kits. A popular tool to analyse suspicious Microsoft Office documents Tools is, part of the oletools package (3), it features YARA when parsing OLE embedded objects in order to identify malware campaigns (read more about it here). When dealing with exploit kits, thug (4), a popular low-interaction honey-client that emulates a web browser, also features YARA for exploit kit family identification. In both cases YARA rule interchanging between the IR teams greatly enhances both triage and analysis of SPAM.

Another use case worth mentioning is forensics. Volatility, a popular memory forensics tool, supports YARA scanning (5) in order to pinpoint suspicious artefacts like processes, files, registry keys or mutexes. Traditionally YARA rules created to parse memory file objects benefit from a wider range of observables when compared to a static file rules, which need to deal with packers and cryptors. On the network forensics counterpart, yaraPcap (6), uses YARA for scan network captures (PCAP) files. Like in the SPAM analysis use case, forensic analysts will be in advantage when using YARA rules to leverage the analysis.

Finally, another noteworthy use case is endpoint scanning. That’s right, YARA scanning at the client computer. Since YARA scanning engine is multi-platform, it poses no problems to use Linux developed signatures on a Windows operating system. The only problem one needs to tackle is on how to distribute the scan engine, pull the rules and push the positive matches to a central location. Hipara, a host intrusion prevention system developed in C, is able to perform YARA file based scans and report results back to a central server (7). Another solution would be to develop an executable python script featuring the YARA module along with REST libraries for pull/push operations. The process have been documented, including conceptual code,  in the SANS paper “Intelligence-Driven Incident Response with YARA” (read it here). This use case stands as the closing of the circle in IOC development, since it enters the realm of live IR, delivering and important advantage in the identification of advanced threats.


The key point lies in the ability for the IR teams to introduce the procedures for YARA rule creation and use. Tier 1 analysts should be instructed on how to use YARA to enhance incident triage, provide rule feedback, concerning false positives, and fine tuning to Tier 2 analyst. Additionally a repository should be created in order to centralize the rules and ensure the use of up-to-date rules. Last but not least teams should also agree on the rule naming scheme, preferably reflecting the taxonomy used for IR. These are some of the key steps for integrating YARA in the IR process, and to prepare teams for the IOC sharing process.


Tagged , , ,

Neutrino Exploit Kit

[First of all Happy New Year to all the readers!
In this summary I would like to briefly describe one component that is part of many parts which form the Internet malware industrial complex. The Exploit Kits (EK’s) which impact users and corporations of all sizes on a daily basis. The
 article below was possible due to the insights and knowledge received from @Kafeine. ~LR]

The EK’s are powerful and modular weapons that deliver malware in an automated fashion to the endpoint by taking advantage of client side vulnerabilities.

Exploit Kits are not new and have been around at least for the past 10 years or so. Nonetheless, they have evolved and are now more sophisticated than ever. The malware authors behind them enforce sophisticated capabilities that evade detection, thwart analysis and deliver reliable exploits. Basically, by introducing malicious code in a web server an attacker can turn a legitimate web server into a mechanism to deliver malicious code by taking advantaged of client-side vulnerabilities against unpatched browsers and applications. This attack vector is known as watering hole or strategic web compromise when it targets a trustworthy web site. In recent years the Exploit Kits have evolved and became very sophisticated weapons and profitable business for the ones involved. The malware authors continue to develop sophisticated capabilities to prevent detection, analysis and deploy exploits for new vulnerabilities in a very reliable manner.

In the last days I had the chance to look at one recent campaign of drive by download that leverages the Neutrino Exploit Kit to infect systems with CryptoWall. The diagram below illustrates the different components of the Neutrino Exploit Kit and how they work together.



  • User browses to the compromised web server.
  • Web server contacts the backend infrastructure in order perform various check and to generate malicious java script code. These checks include things like verification of victim IP address and its Geo-location. Furthermore within the malicious JavaScript code there are new domain names and URLs that are generated dynamically by the backend.
  • The browser processes and decodes the malicious JS. In the observed infection the malicious JavaScript checks the browser version and if it matches the desired version, it stores a cookie and processes a HTML iframe tag.
  • The iframe tag triggers the browser to perform a request to another URL which is the Neutrino Exploit Kit landing page.
  • The landing page is hosted in a randomly generated host using DGA which needs to be resolved via DNS. The authoritative domain to answer these domains are owned by the threat actor. The answers received by the DNS server have a time to live (TTL) of a few seconds. The domains are registered on freely available country code top level domains (ccTLD).
  • The victim then lands in the exploit kit landing page which by its turn delivers a small HTML page with an object tag defined in its body. This object tag directs the browser to load Adobe Flash Player and then use it to play the SWF file specified in the URL. In case the victim does not have Adobe Flash player installed, the browser is instructed to download it.
  • The browser as instructed by the object tag, downloads the malicious Flash file.
  • The obfuscated and encrypted SWF file is played by the Flash Player and exploits are triggered based on available vulnerabilities. The Flash file contains exploits for CVE-2013-2551, CVE-2014-6332, CVE-2015-2419 affecting Internet Explorer and CVE-2014-0569, CVE-2015-7645 affecting Adobe Flash.
  • If the exploitation is successful, shellcode is executed and the malware is downloaded and launched. In this case we observed that the malware delivered has been CryptoWall.

The threat actors behind Neutrino are finding vulnerable websites in order to host their malicious JS  content globally in a repeatable and automated fashion. Furthermore, In the last few days Neutrino has been abusing the registration of free domains registered inside the country code top level domains (ccTLD) such as  .top, .pw, .xyz, .ml, .space and others. The different landing pages have been pointing to a server hosted in Germany and in another cases in Netherlands. In another blog post I will go into more details about it.


References: kit.pdf

Tagged , , , , , ,

Course Review: SANS FOR578 Cyber Threat Intelligence


Image retrieved from

Last week I had the opportunity to attend SANS DFIR Prague where I completed the SANS FOR578 course “Cyber Threat Intelligence” (CTI) with Robert M. Lee.  Robert is one of the co-authors of the course and is brilliant instructor that really knows his stuff.  Everything stands or falls with the quality of the instructor and I believe Robert did give us (students) a great learning experience with great interactions and discussions. Among other things Robert is the CEO of the security company Dragos Security and has worked in the US Air Force which allows him to talk genuinely about the “intelligence” topic.

Overall this was a five day course that immerses the student into the new and emerging field of CTI. During the five days we lived, ate and breathed being a CTI analyst. Being a CTI professional is not an easy task and it’s not in five days that you can expect to become one.  However, in my opinion, if someone has the desire, as well as the ability, this course can give you the means. I’m sure this course gave me important skills and competencies about this new, emerging field. One key take away from the training is that it gives you the foundations to create a threat Intel capability into your organization and enables security personnel to develop more proactive and mature response practices against threats and move defenses higher up the kill chain.

The first day is a comprehensive introduction to the new Cyber Threat Intelligence (CTI) domain, with a wide range of topics and terminology being covered. What is threat intelligence? Why should organizations adopt it? What is the value? What is the difference between a consumer and a producer of CTI? What are the different types of CTI?  In addition, background on the intelligence doctrine and its life cycle is also discussed. The afternoon was spent on the different frameworks and models that you can use to create consistent and repeatable CTI outputs. The Kill Chain, Diamond Model, Courses of Action Matrix and the Detection Maturity Model were the ones most covered.

Day two was all about enforcing the models presented in day one with special focus on the Kill Chain model. Lots of exercises supported by a network intrusion scenario where we (students) needed to perform different tasks to put in practice the theory from day one. The way the intrusion attributes, properties and artifacts are mapped to the Kill Chain, Diamond Model and Courses of Action were really useful. Because the frameworks discussed are complementary they can be combined in order to produce multi-dimensional analysis of the intrusion. I think this multi-dimensional approach to intrusions gives great insight about the adversary. Although a time consuming exercise it was great to get a feeling about what a CTI analyst might do in a organization with high security risk that need to have mature and dedicated teams to perform this type of work.

By leveraging the intelligence gained overtime during the analysis of multiple intrusions we start to get an understanding about commonalities and overlapping indicators. Mapping these commonalities and indicators to the intrusion kill chain and diamond model results in a structural way to analyze multiple intrusions. By repeating this process we could characterize intruders activity by determine the tactics, techniques and procedures on how the attackers operate i.e., perform a campaign analysis. This was day three. A meticulous work that is built over time and needs great amount of support from your organization but after execution it will produce great insight about the adversary. In terms of tools, the exercises relied heavily on Excel and the fantastic and open source Maltego.

Day four was focused on the different collection, sharing and ingestion methods of threat intelligence. The primary method of collection discussed was trough threat feeds.  Other collection methods such as OSINT and threat Intel produced inside the organization or received trough circles of trust were also discussed. For sharing, a key take away is that partners with strong non disclosure agreements are very efficient. Still, in the sharing realm delivering context is crucial in order to make it actionable. Furthermore, we discussed the roles of the different ISAC and other organizations.  Regarding the ingestion, the material has very good coverage on the different standards and protocols that have been developed in recent years to collect share and consume technical information in an automated way. The focus was on STIX, TAXII. We also reviewed other methods and standards such as OpenIOC and Yara rules.  In regards to the tools and exercises we had the chance to play with Recorded Future and Threat Connect and and develop OpenIOC and Yara rules. SANS posture overtime has been always vendor neutral but I must say the Recorded Future demo for OSINT is well worth and the tool is really amazing!

The material on day five is more abstract. Special focus on how people – analysts – make conclusions. For example we discussed the difference between observations and interpretations and how to construct assessments. Great amount of material about cognitive biases and how it might influences the work performed by an analyst. During this day we were also exposed to the analysis of competing hypotheses (ACH) methodology by former CIA analyst Richards J Heuer, Jr. The exercises were really interesting because we had to evaluate hypotheses against the evidences we found during the intrusion analysis of the different scenarios.  By the end of the day we immersed into the topic of attribution and discussion about nation state capabilities and the different cases that have been known in the industry.

Of course apart of the training, was great to attend the DFIR Summit, absorb information, play DIFR NetWars and more important meet new people, share experiences and see good old friends!

Tagged , , , , , ,

Intro to cyber threat intelligence

knowyourenemyThe traditional security monitoring and incident response (IR) capability that has being used across the enterprises in the last decade has fallen behind. It is consensus across the IT security industry that we need a more robust, capable and efficient security monitoring and IR framework. The new framework should enable us to combine security and intelligence functions. An intelligence driven security that allows us to plan for, manage, detect and respond to all categories of threats even as they become more frequent and severe. In other words we want to maximize the organization effectiveness and efficiency to block, detect and respond to attacks. How? By introducing into the traditional security stack the threat intelligence security function we can do more and better.

Following the last post about about what intelligence means and what is the 5 steps of the intelligence cycle below an introduction to  Cyber Threat Intelligence topic.  A quick summary on what is threat intelligence, what is its value and what are the sources to consume or produce intel. More about this topic will follow in future posts.

What is Cyber Threat Intelligence?
Threat intelligence is a recent paradigm in the IT security field that continues to gain a lot of traction due to a change of focus in the risk equation from the vulnerability into the threat. Tracking threats that are specific to your industry, organization or region is key to minimize damage that can caused by an attack.

On the one hand we have strategic threat intelligence. A capability that needs processes, tools and people to leverage an understanding about the attacker’s capabilities and intents. Is normally delivered through reports that are produced by humans and consumed by humans and is the most expensive and hardest to produce. It produces information to support well informed decisions of long-lasting importance such as which policies and processes should change. Or what new changes one should accommodate in the security infrastructure to adapt to the new threat landscape.From a well-established and mature strategic threat intelligence practice you should be able to get answers to questions like: Who is your potential adversary? What is the adversary’s capability to cause you harm? Do they have the intent to cause harm? Where are you vulnerable? How could anyone harm your organization if they wanted to do so?

On the other hand, we have tactical threat intelligence. A capability that aids the prevention, detection and response competencies with real time threat data that is consumed across different systems and functions. Data such as IP addresses, domain names, URLs, email addresses, hashes values, HTTP user agents, registry keys, etc. Remnant pieces of information left by an attacker that can be used to identify threats or malicious actors. These pieces of information are nowadays called indicators of compromise and can, for example, be used to search and identify compromised systems.  This thread data is tactical threat intelligence and is of limited life span. Tactical threat intelligence should be disseminated, integrated and consumed in an automated fashion.  This type of threat intelligence is the cheapest and easiest to create.

What is the value of Cyber Threat Intelligence?
At the strategic level, the value proposition of threat intelligence might include:

  • Make well informed decisions on where you are spending your security dollars.
  • Create comprehensive insight about the threats by developing facts, findings and forecasts about threat actor’s capabilities, motives and tradecraft.
  • Create recommended courses of action on how to adapt to the evolving threat landscape in order to reduce and mitigate risks.
  • Being able to plan for, manage and respond to all categories of threats – even as they become more frequent and more severe.
  • Develop situational awareness about capabilities and intents of your adversaries.
  • Know your adversary and what are they looking for.

At the tactical level, the value proposition of threat intelligence might include:

  • Minimize the risk of attacks that could result in lost revenue, public embarrassment, and regulatory penalties.
  • Improve the effectiveness and efficiency of security monitoring capabilities by integrating and matching threat intel data.
  • Augment security operations and incident response functions with actionable threat data.
  • Reduce the number false positives by adding threat intel data into security operations.
  • Accelerate Incident Response actions and remediation priorities based on targeted information.

What are the sources of Cyber Threat Intelligence?
The sources might vary depending if you are a consumer or a producer of threat intelligence. From a consumer perspective – where the majority of the organizations fit in – they mainly fall into two categories. The open source ones that are free and can be retrieved by anyone. And the closed sources that are commercial or with restricted access. These ones often need a payed subscriptions or being member of a closed circle of trust. Either one, they fall under tactical threat intel when data is delivered to the consumer trough feeds with indicators of compromise. Or they fall under strategic threat intel when the deliverables is a report about capabilities and intents of malicious actors.

From a producer perspective the sources are even broader and using different disciplines. Normally, if you are a service provider there is the incentive to produce it using the most variety of sources, methods and disciplines. Mainly due to the fact service providers do it for a profit. For example, iSight Partners, Dell SecureWorks, Mandiant or CrowdStrike are good examples of service providers that create strategic and tactical threat intelligence combined together. They have dedicated teams of researches that perform all kinds of activities, some of which might be almost considered under intel agencies or law enforcement umbrella. Examples of sources used across producers are honeypots and spam traps that are used to gather intelligence trough the knowledge and information that one could obtain by observing, analyzing and investigating the attacker that are lured to it. Another source could be the output of doing static and dynamic malware analysis.


How to Collect, Refine, Utilize and Create Threat Intelligence by Anton Chuvakin
Security Science by Clifton Smith; David J Brooks
Intelligence-Based Security in Private Industry by Thomas A. Trier

Tagged , ,

Security Hands-On-Training – Part 6 – Final

The previous blog post illustrated how someone with malicious intent could pull off a way to compromise a system. It starts by gaining access to the system using a SQL injection. After the initial access a foothold is established. Then the position is strengthen by uploading the tools of choice. Next the privileges are escalated and a shell with full systems privileges is gained.

However, this attack method might seem complex it would probably happen in case there is a motive or incentive for the attacker do it. An incentive to do such activity could be to steal trade secrets, intellectual property, credit cards or any other information that the attacker could monetize. Nonetheless, there are other motives that serve as an incentive for an attacker to compromise a system. Brian Krebs, a former Washington Post reporter, has putted together a great chart listing the various ways the bad guys can monetize hacked systems (Krebs, 2012).  One of the attack methods that tend to gain popularity is to use SQL injection for malware distribution. Basically, by introducing malicious code in the web server an attacker can turn the web server in a mechanism to deliver malicious code to browsers by taking advantaged of client-side vulnerabilities against unpatched browsers. This mechanism was used by the Asprox botnet (Borgaonkar, 2010) (Pelaez, 2008).  More recently this attack gained the connotation of watering hole or strategic web compromise when it targets a trustworthy web site (Kindlund, Caselden & Chen, 2014). Steven Adair and Ned Moran explain it perfectly in his article about trusted websites delivering dangerous results (Adair & Moran, 2012).

How does an attacker performs this? What are the mechanics behind such method? As the reader noticed in the previous attack scenario there were some key aspects that would be important for the attacker to be successful. One item is the xp_cmdshell stored procedure being enable or the ability to have an out-of-band channel to accelerate the speed of the time based SQL injection technique. But, in the watering hole attack scenario there is no need of any of those factors. The attacker will only need a SQL injection point and from there it can inject malicious script that will be appended trough out the database. As consequence, when a user browses to the web page, the data is retrieved from the database and rendered in the browser. Then the malicious code is executed putting him at mercy of all kind of client-side exploits.

Figure below illustrate these steps using a SQL statement that is famous due to the Asprox Trojan (Analysis, 2008) (Shin, Myers & Gupta, 2009). It  uses a special table in the SQL server sysobjects and syscolumns in an attempt to get access to the “user” defined tables and fields in the website’s database. Through a loop it goes through every table columns and appends a string containing the malicious <script> tag.

This SQL statement is encoded in a hex format and inserted into another SQL statement in order to evade defenses.  The reader can practice this technique and use SQLmap to invoke a SQL shell that allows to execute SQL statements.  Then this prepared statement is executed which will result in infecting the database data. For reference a picture of what DBA will see if he looks into is affected database is also shown.


From this moment onwards the web server is infected. When a user goes in and browses trough the infected web pages it will download and execute the evil Java Script within the <> tags (Stuck, 2009) (Mendrez, 2009). This evil script can do, among other things, scan the visitor machine for client side vulnerabilities and deliver the appropriate exploit payload. Similar to using guided missiles this attack can be very effective and is worth to mention James Lee presentation “Using Guided Missiles in Drive­bys  at Defcon 17“.

As demonstrated using this environment the reader could get a practical understanding of how a typical watering hole attack is executed. The next step might be to explore the client side vulnerabilities and exploits by taking advantage of the evil script that is inserted into the database.  The reader is encouraged to further learn, practice and explore this vector of attack with tools such as the Browser Exploitation Framework (BeEF) developed by Wade Alcorn and others, or  the Social Engineering Toolkit (SET) from David Kennedy.

Continuing the Journey

Even though the tools used are extremely functional and almost no knowledge is needed to run an exploit against a vulnerable server using SQLmap or Metasploit this is the first step in building hands-on information security skills. Some techniques used are low hanging fruit. Nonetheless, the reader should start with them in order to advance to more complex methods and techniques using incremental approach.  A proposed next step would be to further expand this environment to model business networks with end point and boundary defenses such as a Proxy, an IDS/IPS, a HIDS, etc. Also introduce Linux based systems such as an e-commerce and test other techniques and exploits (Rocha, 2012). As well, the reader could create scenario based challenges and simulations like Ed Skoudis promotes on his presentation “Using InfoSec Challenges to build your skills and career” that can emphasize the development of critical thinking (Skoudis, 2012).

Further practice reconnaissance, scanning, exploitation, keeping access and covering tracks will be doable. In addition to offensive skills the reader might want to practice defensive skills. When the attacker launches a specific technique  how does it look like? Which opportunities does it bring from a defender to identify and detect it from the network or database level? How does it look at the operating system level. How would the reader be able to better prepare, identify, contain, eradicate and recover from each one of these and other attack scenarios. Could the correlation between the logs from the DNS server and Database server be used to detect such incident? Which IDS signatures would be needed to detect this kind of traffic? This and other suggestions have been also encouraged throughout the previous chapters.

It’s this never ending cat and mice game which makes our industry a very interesting place to be at. Like when playing a game, It involves defenders trying to build a secure system, then how to innovate, progress and take it to the next level by circumvent those measures using different tools and techniques. Then the defender improves the system and so on. This healthy competition between the attacker and the defender will make us smarter and better at security. As Jon Erickson mention on his book “The net result of this interaction is positive, as it produces smarter people, improved security, more stable software, inventive problem-solving techniques, and even a new economy”.


Although there are plenty of books and open source information that describe the methods and techniques demonstrated, the environment was built from scratch.  The tools and tactics used are not new. However, they are relevant and used in today’s attacks. Likewise, the reader can learn, practice and look behind the scenes to better know them and the impact they have.

The main goal was to demonstrate that hand’s on training is a very valuable and cost efficient training delivery method that allows a better practical understanding on security. This method has advantages to build up your skills – not only from an incident handling and hacking techniques perspective but also from a forensics perspective.  One can practice and improve their ability to determine past actions which have taken place and understand all kinds of artifacts which occur within the outlined scenarios. For instance, one could simulate an actual forensic investigation!  On the other hand, from an Intrusion Analyst’s perspective the reader can capture the full contents of the network packets during the exercises and work on mastering his TCP/IP and intrusion detection techniques. In addition to that, the data set can be also feed to intrusion detection devices in order to measure how effective will they be in detecting the attacks.

Practice these kind of skills, share your experiences, get feedback, repeat the practice, grow to be proficient,  improve your performance and become fluent.




Krebs, B. (2012, 10 15). The scrap value of a hacked pc, revisited. Retrieved from
Borgaonkar, R. (2010). An analysis of the asprox botnet. Manuscript submitted for publication, .
Pelaez, M. (2008, 8 15). Obfuscated sql injection attacks. Retrieved from SQL Injection attacks/9397
Kindlund, D., Caselden, D., & Chen, X. (2014, 02). [Web log message]. Retrieved from
Adair, S., & Moran, N. (2012, 05 12). [Web log message]. Retrieved from
Analysis, X. (2008). Asprox trojan and . Retrieved from
Shin, Y., Myers, S., & Gupta, M. (2009). A case study on asprox infection dynamics. Manuscript submitted for publication, Computer Science Department, Indiana University, .
Stuck, F. (2009). An overview of a sql injection attack. Retrieved from
Mendrez, R. (2009). Another round of asprox sql injection attacks. Retrieved from
Rocha, L. (2012, Nov 23). Hands-on lab – ecommerce – part 1. Retrieved from
Skoudis, E. (2012, March). [Web log message]. Retrieved from

Tagged , , , , , , , , , ,