Category Archives: Threat Intelligence

Aug 17 2016
6 Comments
Malware Analysis, Threat Intelligence

Malware Analysis – Dridex Loader – Part I

It has been quite some time since the article “Malware Analysis – Dridex & Process Hollowing” where we went over the analysis of banking trojan known as Dridex and how it leverages a technique known as process hollowing to extract an unpacked version of itself into memory. In that article, we briefly explained this technique and used OllyDbg to illustrate the different steps. Today, we will continue where we left off, extract the unpacked sample from memory and continue the analysis. This unpacked sample is known as the Loader. The Loader is what we will be looking at. We will mainly use a debugger to perform our analysis in order to understand more about what it does and get visibility into its functionality.  Please note that a bit of familiarity with OllyDbg is needed in order to follow the steps described.

You might want to read the last article and read more about the process hollowing technique in order to situate yourself before we start. As a refresher, the last step we did was to use OllyDbg to set a breakpoint on WriteProcessMemory() API and execute the binary. Once the breakpoint was reached we could see the moment before WriteProcessMemory() API was called and the different arguments in the stack.

In OllyDbg in the stack view (bottom right) we could see that one of the arguments is buffer. The data stored in this buffer is of particular interest to us because it contains the contents of the malicious code that is going to be written to the legitimate process i.e., the unpacked sample.

So, to continue our analysis we need to extract the unpacked sample into disk. We can perform this by saving contents of the buffer argument from the WriteProcessMemory() API into a file. In OllyDbg, in the memory view (bottom left) we right click – Backup – Save data to file and save the file with the suggested name _009C0000.mem.

dridex-unpackedsample

With the binary extracted we can, again. start the initial steps of malware analysis. As normal we perform basic static analysis in 3 steps. The first step is to profile the file. We can easily determine its an PE32 executable file using the Linux “file” command. In addition, we compute the MD5 of the file which is c2955759f3edea2111436a12811440e1. With this fingerprint we can search different online tools such as VirusTotal in order to find further information about it.

Second step is to run the strings command against the binary. The strings command will display printable ASCII and UNICODE strings that are embedded within the file. This can disclose information about the binary functionality.

The third step is to use some tool like the PE Analysis Toolkit from Fernando Mercês or CFF explorer from Daniel Pisteli to analyze the Win32 PE headers. Extracting information from the PE headers can reveal information about API calls that are imported and exported by the program. It can also disclose date and time of the compilation and other embedded data of interest. The binary contains library dependencies and these dependencies can be looked at in order to infer functionality through static analysis. These dependencies are included in the Import Address Table (IAT) section of the PE structure so the Windows loader (ntdll.dll) can know which dll’s and functions are needed for the binary to properly run.

Noteworthy, is that in this binary, the PE headers don’t contain an Import Directory and we are unable to determine its dependencies because the IAT is missing. This makes this binary more stealthier and more complex to analyze. As result we will need to load this sample into OllyDbg and try to find out more information about it while stepping throughout the code. The binary needs to somehow resolve the Imports.

Dridex is known to use different techniques to encode and obfuscate data.  This sample is no different. We open the _009C0000.mem file into OllyDbg and while going back and forth and stepping into the different functions, we can observe that in the beginning of the execution there is a XOR function that is performed. By following the memory addresses that are used across the different function arguments from the different routines, and looking in detail into the memory and stack pane we can see that the names of the different API calls start to appear. There is a function at virtual address 0x00406c0f  that performs XOR of a chunk of data stored at virtual address 0x0040f060. It uses 2 XOR 32-bits keys. In the picture below you can see in the dissasembler window (top left) the instruction that loads the first XOR key into the register EAX. By following the function loop and see the content of the memory addresses we would be able to see that LoadLibraryA() API appears as string.

Because going over the loop in OllyDbg and observe the API calls being resolved is a tedious process we can perform the decoding offline. We know where the chunk of data starts and the XOR keys. So, we can save the chunk of data into a file in order to perform the decoding and get all the data. To do this in OllyDbg, we set a breakpoint in the XOR function at virtual address 0x00406c0f, In the dissasembler window (top left), Ctrl + G and in the expression to follow dialog box enter the function address. Then press F2 to set a breakpoint in that line. Then hit F9 to run the sample. It will pause the execution when the breakpoint is hit. Then press F7 to step into each instruction until you hit the function that loads the first XOR key at address 0x00406c36. Then go into to the Memory dump window (Bottom left corner), hit Ctrl + G and insert the memory address 0x0040f060. Then select the data until you see a series of null bytes. Right click and choose Binary – Binary Copy. Below a print screen of this step.

dridex-xor-imports

Then we can paste the data to a text file and use a small python script to perform the XOR decoding using the obtained keys and see that the binary has an extensive list of 355 imported functions.

dridex-importsdecoding

This was the first XOR operation. Then after decoding the API it needs, the binary decodes the chunk of data stored at 0x00414c20 and gets the names of the libraries like kernel32.dll, ntdll.dll and others.  This operation is performed by a function stored at Virtual Address 0x0040d42f. In the picture below you can see in the dissasembler window (top left) the instruction that loads the first XOR key into the register EAX.

dridex-xor-libraries

Using the same technique has previously described, we can save this chunk of data into a file and perform the XOR decoding in order to get the list of libraries that are used by the binary.

dridex-librariesdecoding

The strings decoding happens throughout the execution. There are 5 chunks of data that are decoded using XOR and 2 x 32-bits keys. The below table shows the XOR keys and the offset address of the data and functions that are called in order to decode the strings:

dridex-datachunks

By decoding all the chunks we get visibility into the binary functionality and can deduce its malicious intent. For the sake of brevity and because the list of strings is quite extensive, this is left as exercise to the reader. Nonetheless, below is a small portion of the decoded strings. These ones are associated with the UAC bypass technique used by Dridex to get Admin rights.

dridex-strings

That’s it for part 1. On part 2 we will look into how the C&C addresses are obtained and some of the techniques used by Dridex to generate the XML messages used by the loader.

Sample MD5: c2955759f3edea2111436a12811440e1

References:

Click to access dridex-financial-trojan.pdf

https://www.cert.pl/news/single/talking-dridex-part-0-inside-the-dropper/

http://christophe.rieunier.name/securite/Dridex/20150608_dropper/Dridex_dropper_analysis.php

https://www.virusbulletin.com/virusbulletin/2015/07/dridex-wild/

Click to access SAR-PR-2015-01_.pdf

Click to access ANB_MIR_Dridex_PRv7_final.pdf

https://www.lexsi.com/securityhub/how-dridex-stores-its-configuration-in-registry/?lang=en

http://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html

Click to access Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf

 

Tagged , , ,
Mar 09 2016
7 Comments
Digital Forensics and Incident Response, Malware Analysis, Threat Intelligence

Unleashing YARA – Part 3

yara-logoIn the second post of this series we introduced an incident response challenge based on the static analysis of a suspicious executable file. The challenge featured 6 indicators that needed to be extracted from the analysis in order to create a YARA rule to match the suspicious file. In part 3 we will step through YARA’s PE, Hash and Math modules functions and how they can help you to meet the challenge objectives. Lets recap the challenge objectives and map it with the indicators we extracted from static analysis:

  1. a suspicious string that seems to be related with debug information
    • dddd.pdb
  2. the MD5 hash of the .text section
    • 2a7865468f9de73a531f0ce00750ed17
  3. the .rsrc section with high entropy
    • .rsrc entropy is 7.98
  4. the symbol GetTickCount import
    • Kernel32.dll GetTickCount is present in the IAT
  5. the rich signature XOR key
    • 2290058151
  6. must be a Windows executable file
    • 0x4D5A (MZ) found at file offset zero

In part 2 we created a YARA rule file named rule.yar, with the following content:

import "pe"

If you remember the exercise, we needed the PE module in order to parse the sample and extract the Rich signature XOR key. We will use this rule file to develop the remaining code.

The debug information string

In part 1 I have introduced YARA along with the rule format, featuring the strings and condition sections. When you add the dddd.pdb string condition the rule code should be something like:

yara_3_1

The code above depicts a simple rule object made of a single string variable named $str01 with the value set to the debug string we found.

The section hash condition

Next item to be added to the condition is the .text section hash, using both PE and HASH modules. To do so we will iterate over the PE file sections using two PE module functions: the number_of_sections and sections. The former will be used to iterate over the PE sections, the latter will allow us to fetch section raw_data_offset, or file offset, and raw_data_size, that will be passed as arguments to md5 hash function, in order to compute the md5 hash of the section data:

yara_3_2

The condition expression now features the for operator comprising two conditions: the section md5 hash and the section name. In essence, YARA will loop through every PE section until it finds a match on the section hash and name.

The resource entropy value

Its now time to add the resource entropy condition. To do so, we will rely on the math module, which will allow us to calculate the entropy of a given size of bytes. Again we will need to iterate over the PE sections using two conditions: the section entropy and the section name (.rsrc):

yara_3_3

Again we will loop until we find a match, that is a section named .rsrc with entropy above or equal to 7.0. Remember that entropy minimum value is 0.0 and maximum is 8.0, therefore 7.0 is considered high entropy and is frequently associated with packing [1]. Bear in mind that compressed data like images and other types of media can display high entropy, which might result in some false positives [2].

The GetTickCount import

Lets continue improving our YARA rule by adding the GetTickCount import to the condition. For this purpose lets use the PE module imports function that will take two arguments: the library and the DLL name. The GetTickCount function is exported by Kernel32.DLL, so when we passe these arguments to the pe.imports function the rule condition becomes:

yara_3_4

Please note that the DLL name is case insensitive [3].

The XOR key

Our YARA rule is almost complete, we now need to add the rich signature key to the condition. In this particular case the PE module provides the rich_signature function which allow us to match various attributes of the rich signature, in this case the key. The key will be de decimal value of dword used to encode the contents with XOR:

yara_3_5

Remember that the XOR key can be obtained either by inspecting the file with a hexdump of the PE header or using YARA PE module parsing capabilities, detailed in part 2 of this series.

The PE file type

Ok, we are almost done. The last condition will ensure that the file is a portable executable file. In part two of this series we did a quick hex dump of the samples header, which revealed the MZ (ASCII) at file offset zero, a common file signature for PE files. We will use the YARA int## functions to access data at a given position. The int## functions read 8, 16 and 32 bits signed integers, whereas the uint## reads unsigned integers. Both 16 and 32 bits are considered to be little-endian, for big-endian use int##be or uint##be.

Since checking only the first two bytes of the file can lead to false positives we can use a little trick to ensure the file is a PE, by looking for particular PE header values. Specifically we will check for the IMAGE_NT_HEADER Signature member, a dword with value “PE\0\0”. Since the signature file offset is variable we will need to rely on the IMAGE_DOS_HEADER e_lfanew field. e_lfanew value is the 4 byte physical offset of the PE Signature and its located at physical offset 0x3C [4].

With the conditions “MZ” and “PE\0\0” and respective offsets we will use uint16 and uint32 respectively:

yara_3_6

Note how we use the e_lfanew value to pivot the PE Signature, the first uint32 function output, the 0x3C offset, is used as argument in the second uint32 function, which must match the expected value “PE\0\0”.

Conclusion

Ok! We are done, last step is to test the rule against the file using the YARA tool and our brand new rule file rule.yar:

yara_3_7

YARA scans the file and, as expected, outputs the rule matched rule ID, in our case malware001.

A final word on YARA performance

While YARA performance might be of little importance if you are scanning a dozen of files, poorly written rules can impact significantly when scanning thousands or millions of files. As a rule of thumb you are advised to avoid using regex statements. Additionally you should ensure that false conditions appear first in the rules condition, this feature is named short-circuit evaluation and it was introduced in YARA 3.4.0 [5]. So how can we improve the rule we just created, in order to leverage YARA performance? In this case we can move the last condition, the PE file check signature, to the top of the statement, by doing so we will avoid checking for the PE header conditions if the file is an executable (i.e. PDF, DOC, etc). Lets see how the new rule looks like:

yara_3_8

If you like to learn more about YARA performance, check the Yara performance guidelines by Florian Roth, as it features lots of tips to keep your YARA rules resource friendly.

References

  1. Structural Entropy Analysis for Automated Malware Classification
  2. Practical Malware Analysis, The Hands-On Guide to Dissecting Malicious Software, Page 283.
  3. YARA Documentation v.3.4.0, PE Module
  4. The Portable Executable File Format
  5. YARA 3.4.0 Release notes
Tagged , ,
Feb 29 2016
Leave a comment
Malware Analysis, Threat Intelligence

Retefe Banking Trojan

mtanBack in 2014, Retefe banking trojan started to appear in the news. First appearance in public was in a blog post from the Microsoft Threat Research & Response team. Then in July 2014, David Sancho from Trend Micro wrote the first public report about it. A video from Botconf about this research is also available here. Following that a great write-up by Daniel Stirnimann from SWITCH-CERT is here and here. Time as passed and the threat actors behind Retefe continue to evolve and adopt new techniques to  commit fraud.

In the past, Retefe has maintained a low profile when compared with other Banking trojans. It is known to target users in Sweden, Austria, Switzerland and Japan. Retefe is an interesting banking trojan because is designed to bypass the two-factor authentication scheme (mTAN) used by different banks by encouraging the victims to install a fake app. mTANs (Mobile Transaction Authentication Number) are used by banks as a second factor authentication. When the user tries to login to the bank or perform a transaction a SMS is sent to the user’s mobile phone. Retefe is then able to hijack the SMS’s.

The threat actors behind the Retefe malware use phishing emails as main infection vector. The emails are tailored to match the country that they are targeting. In Switzerland for example, the lures take advantage of social engineering techniques by impersonating institutions like Zalando and Ricardo to trick the users into executing the malware. One recent phishing campaign contained a ZIP with a malicious executable inside (SHA1 : 32ed8fb57e914d4f906e52328156f0e457d86761). The image below illustrates one of these emails. The sender falsely mimics a legitimate business transaction from Zalando.

retefe-phishing

When installed, the Retefe Trojan adds a self-signed certificate authority (CA) root certificate to the victim’s browser certificate store. In this version the operation occurs in memory and the certificate is written to the Registry Key HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\Certificates\<random number> where random number matches the Thumbprint of the certificate. This technique allows the threat actor to perform man-in-the-middle attacks and intercept or modify information from the banking site. The below picture shows the self signed certificate used in this campaign.

retefe-fakecert

At execution the first request is a HTTP request to checkip.dyndns.com or icanhazip.com in order to determine the victim public IP address. Interesting the request does not have an User-Agent. The IP addresses value returned is then used to append to another request which is used to retrieve the Proxy PAC config  that is written to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL setting in the registry. This setting modifies the victim browser Proxy-PAC setting that allows the traffic to be redirected to a malicious proxy server.

retefe-proxypacreg

The Proxy-PAC configuration in this campaign is retrieved from different TOR websites. The code is a slightly obfuscated JavaScript. The picture below shows the answer received from the TOR website. The answer is tailored based on the IP address of the victim . In this case the payload being delivered is targeted to Switzerland.

retefe-requestproxypac

After deobfuscation we can see the hosts that are being targeted. With this configuration all the traffic that matches the targeted Swiss Banks will be redirected to a SOCKS proxy which is hosted in Russia. The redirection only occurs if it meets the conditions from the Proxy-PAC file. Otherwise the traffic is forwarded without the use of the SOCKS proxy. When browsing the internet, if the traffic matches one of the hosts defined in the Proxy-PAC configuration file then the traffic gets redirected to the SOCKS proxy. This will allows the threat actors to intercept and modify all traffic at will. When browsing to the login page of one of the banks targeted in this campaign, the victim lands on a phishing page that mimics the bank web site and prompts the user with a pop-up message. This message attempts to lure the users that the appearance of the online banking site has been renewed and new features are waiting to be discovered!

retefe-cslogin

After clicking OK the user is prompted to enter his credentials. Then the user is presented with a pop-up message asking him to wait – behind the scenes the credentials are sent to the threat actor.  The user is then prompted to confirm what type of second factor authentication he currently uses. He can choose SMS or RSA token as second factor authentication. Following the selection of SMS as second factor authentication the user is asked about his mobile phone number and mobile operating system.

retefe-csmtan

Current version of Retefe only targets Android phones. After entering a mobile phone, the user will be prompted to install a new banking mobile application. The victim will receive a SMS on his mobile phone asking to install the new APK. The APK is hosted on a site owned by the threat actors. One example of an APK is CreditSuisse-Security-v-07_02 1.apk (sha1: 4bdc5ccd3e6aa70b3e601e1b4b23beaf09f33d7a).  If for some reason the victim does not receive the SMS, then a screen is shown in order to encourage the installation of it using a QR code.

retefe-cscode

Installing the Android app allows the attacker to gain full control over the victims phone and among other things hijack the SMS’s sent by the Bank and take control over the users online banking session. The picture below illustrates the initial setup screen of the APK installation.

maliciousapkinst3

The code, functionality and the C&C protocol of the APK has been researched extensively by Angel Alonso-Párrizas in a series of articles including here, here and here. The APK is an adaptation of the Signal Android APK (a.k.a. Text Secure) from Moxie Marlinspike.  Among other features allows one to store and send encrypted text messages.  The figure below shows some of the permissions that are granted to this malicious APK.

maliciousapkinst5

In this case the threat actors reused the code from Signal Android to implement the the  Command and control (C2) communication. The traffic uses the Blowfish symmetric algorithm. It communicates with a primary C2 and if it fails it tries a backup address. The C2 addresses are stored in file named config.cfg which can be found in the decompiled APK. The data stored in the config.cfg and the traffic can be decrypted with Blowfish in CBC chaining mode. The key and IV used is also stored in the APK. The picture below shows the decrypted configuration file which contains the addresses of two compromised servers that are used to then communicate to the Retefe backend.

retefe-apkconfig

As soon as the APK is installed and launched it starts beaconing out to the C2 address. The C2 traffic is encrypted using the Blowfish encryption algorithm, and the traffic uses HTTP.

retefe-apkcnctraffic

The encrypted information contains details about the victim’s mobile device, including the SIM country, operator, serial number, IMEI, phone number, model and brand. The below figure shows the decrypted traffic. In this decrypted traffic there is a block of base64 data which decoded will give the mobile device information.

retefe-trafficdecoded

Meanwhile, in the banking session the user is asked to enter the OTP (One Time Password) code seen in the fake mobile app. From this moment onward the threat actors are in possession of the username, password and mTAN which allow them to commit fraudulent payments. In addition they have control over the victims mobile phone and can send real-time instructions via SMS. See Angel’s article here and TrendMicro here about the different SMS C2 commands.

This particular malware can be identified by the home users when they are browsing to the Banking website because it breaks the EV SSL certificate seen in the browsers. This does not occur with other types of banking malware. The Counter Threat Unit from Dell SecureWorks just recently released the “Banking Botnets: The Battle Continues” article that contains about the top banking malware seen in 2015.

Moving from the traditional internet banking to a more mobile experience is a fast growing trend. This will fuel the adoption of new techniques by the threat actors in order to leverage the digital channels to commit fraud. Banking trojans are sophisticated threats that leverage technology and social engineering and are here to stay!

Phishing campaigns that distribute banking malware are common and ongoing problem for end users and corporations.E-mail continues to be the weapon of choice   for mass delivering malware. The tools and techniques used by attackers  continue to evolve and bypass the security controls in place. From a defense perspective, the US-CERT put together excellent tips for detecting and preventing this type of malware and to avoid scams and phishing attempts applicable to home users and corporations.

 

 

Tagged , , ,
Feb 10 2016
Leave a comment
Digital Forensics and Incident Response, Intrusion Analysis, Malware Analysis, Threat Intelligence

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]

Intro

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
{
    strings:
        $ascii_01 = "mozart.pdb"
        $byte_01  = { 44 65 6d 6f 63 72 61 63 79 }
    condition:
        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 olevba.py, 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.

Conclusion

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.

References:

  1. https://github.com/plusvic/yara
  2. https://plusvic.github.io/yara
  3. https://blog.didierstevens.com/2014/12/17/introducing-oledump-py
  4. https://github.com/buffer/thug
  5. https://github.com/volatilityfoundation/volatility
  6. https://github.com/kevthehermit/YaraPcap
  7. https://github.com/jbc22/hipara
Tagged , , ,
Oct 20 2015
Leave a comment
Intrusion Analysis, Threat Intelligence

Course Review: SANS FOR578 Cyber Threat Intelligence

KillChain

Image retrieved from lockheedmartin.com

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 , , , , , ,
Aug 19 2015
Leave a comment
Intrusion Analysis, Security Monitoring, Threat Intelligence

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.

 

References:
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 , ,
Aug 15 2015
2 Comments
Security Monitoring, Threat Intelligence

The 5 steps of the Intelligence cycle

intelligencecycleBack in 2011, market research companies like IDC, Forrester and Frost & Sullivan were making market analysis about the growth of cyber threat intelligence services and alike. Their analysis stated a double digit growth year of year. Their projections seem reasonable and their current estimations continue in this trajectory.  Nowadays, cyber threat intelligence continues to gain a lot of traction and hype across IT security. However, as many other cases in the IT security, the industry is adopting the jargon used across government agencies and military forces. That being said I wanted to write about cyber threat intelligence. But I thought would be good to first read and understand what intelligence means across the intelligence agencies and military domains in order to have good foundation before applying it to cyber. Below short summary I made on what intelligence is and what the 5 steps of the intelligence are.

What is Intelligence?

Intelligence is the product that results from a set of actions that are performed to information.  Traditionally, used across governmental organizations for the purpose of national security.  The actions are collect, analyze, integrate, interpret and disseminate. The final product of intelligence gives value-added, tailed information that provides an organization or its adversary, the ability to make conclusions. For the enterprise the information product might be to seek information about the threat actors means, motive and capabilities. On the other hand the adversary might want to seek information about intellectual property (patents, copyrights, trademarks, trade secrets, etc) from your company in order to gain economical advantage or to subvert its interests. In any of the cases the information produced gives an edge, a competitive advantage to you or to your adversary.

The information produced contains facts, findings and forecasts that supports yours or the adversary goals.  There are two categories of Intelligence. One is strategic and the other is operational. Strategic intelligence means information produced to support well informed decisions of long-lasting importance. Strategic intelligence is broader and often requires information concerning different fields.  Operational intelligence is of limited life span and it to be used rapidly and is concerned with current events and capability.

What are the 5 steps of the Intelligence cycle?

Planning and direction – This is the first step. It’s here were the requirements and priorities are set. The capabilities to produce Intel are limited as any other resource which means we want to maximize its production with a constant number of resources.  Among others, a methodology to define the requirements might be using the “Five W’s”. It’s also in this step where we define which areas the intelligence produced will have the most impact and make to most contribution.  During the planning is fundamental to specify which categories of Intelligence will be gathered i.e. OSINT (Open Source Intelligence). In addition, the processes, people and technology to support the different steps in the cycle need to be established with clear roles and responsibilities.

Collection – The second step includes all the different activities, mainly research, that involves the collection of data to satisfy the requirements that were defined. The collection can be done either via technical or human means and involves gathering data from a variety of sources.  In the military and intelligence community the sources normally used are people, objects, emanations, records. These sources span the different collection disciplines named as HUMINT, IMINT, MASINT, SIGNT, OSINT and others. Once collected, information is correlated and forwarded for processing and production.

Processing and exploitation – Third step, the collected raw data starts to be interpreted, translated and converted into a form suitable for the consumers of the intelligence. The raw data becomes information.

Analysis and production – The refinement of the information that was produced in the previous step.  The fusion of the different information that was processed from the different intelligence disciplines. These are key tasks performed during this step. The analysis  consists of facts, findings and forecasts that describe the element of study and allow the estimation and anticipation of events and outcomes. The analysis should be objective, timely, and most importantly accurate.  To produce intelligence objectively, the analysts apply four basic types of reasoning. Induction, deduction, abduction and the scientific method. Furthermore, because bias and misperceptions can influence the analysis the analyst should be aware of the different analytical pitfalls. The outcome is value-added actionable information tailored to a specific need. For example,  in the United States, creating finished intelligence for national and military purposes is the role of the CIA.

Dissemination and Integration – Essentially, this step consists in delivering the finished product to the consumers who requested the information. This can be done using a wide range of formats and in a manual or automated manner.

References:
JP 2-0, Joint Intelligence
Operations Security – Intelligence Threat Handbook
USAF Intelligence Targeting Guide
Intelligence Essentials for Everyone

 

Tagged , , , ,
← Older posts
Newer posts →