Profiling the adversary : Target Determination

Readers!

As mentioned on my recent LinkedIn update, this is the first blog article in this series about what our adversaries do and from their objectives/actions how a target can learn.

Executives or higher management asks mostly following questions :

  • What is current threat landscape ?
  • How do we protect our organisation ?
  • What is targeting us ?
  • What are our current cyber security risks ?
  • Are we getting return on investment from the the products we have ?

Mostly the executive summary is trying to answer these questions – sometimes other. We always looks for the answers to these questions from our vendors, internal teams etc. However, are we asking right questions ? How about,

  • Why are they targeting us ?
  • What kind of information they are after ? Why ?
  • What kind of data/information they are leveraging ?

To answer these questions we need a combination, to profile what adversaries are doing and what we know about our own organisation.

Based on my experience, I have noticed that there are very few documentation or approaches out there with regards to what Targets (organisations not individual users) should be doing before and after any adversary targets and attacks them. Normally, vendors or organisations follow a framework or a model that is out there.

Lockheed Martin’s Cyber Kill Chain is a good model to understand attackers actions  and understanding their objectives and how an organisation as a victim can defend themselves. However, in my hypotheses before targeting an individual or an organisation or a nation, one must first determine the target. This determination is based on INTENT, MOTIVE and CAPABILITY of an attacker/adversary.

Mission of the blog is to understand what steps does attackers/adversaries take, profile them based on the steps taken and as a target what we are suppose to do. Seems like we perform reconnaissance ourselves. Many organisations put this under Reconnaissance phase (Information Gathering), which is wrong. Consider you are traveling :

  • Target : I have 4 days of holidays I will go to place A.
  • Reconnaissance : How do i get there, means of transportation, which hotel to stay in etc

You can see clear differences between the two.

At the end of series, the goal will be to profile attackers, their objectives and what tools, techniques and procedures they use and how we can defend ourselves or at least be pro-active in our incident response. Of what I have mentioned, likely is known globally but, still hoping to spread the word. Later, will also try to match with Diamond model which is very useful in understanding an Attacker and their capabilities.

Every attacker/adversary has an INTENT and MOTIVE to perform an attack or target an entity and for a successful attack their capabilities are also important. From highly sophisticated to script kiddies they have certain objectives. However, intent and motives are majorly used in law and justice field and not on threat report. At-least the reports that I have seen does not mention it. In my opinion, the fields is not only when we have to go to court, but we can also use it to understand our adversaries and  prepare ourselves.

This being said, for me the first phase should be Target Determination or Determining a target, that fits attackers/adversaries objectives. Recently, MITRE has updated the TTP matrix with Pre-ATTACK. The matrix provides the ability to prevent an attack before the adversary has a chance to get in.

We can distribute attackers/adversaries into two groups :

  1. Insiders – Disgruntled employees,
  2. Outsiders – Ex-Employees, Nation State attackers, cyber criminals, script kiddies, hacktivists etc.

Few motivations/intentions :

  1. Financial gain
  2. Fame or generate vouches – Require to gain trust of underground or group of hackers
  3. Intellectual challenges
  4. Damage or disrupt services
  5. Cyber espionage
  6. Personal grievances.
  7. Political motivation
  8. Terrorism

Intentions are sometimes hard to prove, but mostly our adversaries will have malicious intentions.

Only after deciding a Target, they will perform Reconnaissance or Target Profiling. Now, where the attackers/adversaries look is depending on the target or what motivates them. Target can be a single entity or an organisation or a nation/country that accomplishes their intentions/motivations.

Single entity as a target – Individuals are mostly targeted for their personal data. Their personal data such as credentials of their email address, online banking, medical data etc. These information are normally sold on forums and/or marketplaces. Other example is targeting individuals with high positions in corporate places or an institution.

Organisation as a target  An attacker have varied intentions in targeting organisation. Damaging reputation, personal grudge, financial gain or sometimes part of conspiracy and/or nation state attacks.

Nation/Country as a target – This is mostly politically motivated and intentions are mostly malicious towards harming the nation or a country and its infrastructure. Disrupting day to day services that affects human life is also an intent. Recent example – NotPetya malware attack to Ukraine. Here, attackers/adversaries understood their target and profiled them and launched the attack.

In all cases, the better an attacker/adversary profiles their target the better the attack will be.

For individual users, beside security awareness, being careful is the key here. The information that they share or provide can be used to target them. During a presentation I came up with the following tagline.

“Charity begins at home and intelligence begins with your logs”

So attackers/adversaries spend days, weeks or months to collect information about their target, as an organisation for example, you already have this information but,  not using to gain tactical advantage over our adversaries. So what should a targets do ?

  1. Take time to understand your organisation. Understand what information do you have floating on the network and sitting on the systems.
  2. Should know type of information available publicly and understand the risk and how it can be used by an attacker and type of attacks that can leverage these information.
  3. One must take this into consideration that attackers will use available tools to assist them. Mostly these tools are available or sold in underground marketplaces. Being aware of the tools is good way to start. These tools are their weapons and we must know how an enemy weapons work to defend against them. For every poison there is an antidote.
  4. Further action on any successful breaches and data exfilteration beside incident response and BAU activities. If email address were seen on pastebin don’t just change credentials but also understand that these email addresses will be used for phishing or spoofing. Ideal is to change email address and convert the breached one into honeypot email addresses. This will help understand type of attackers targeting your organisation. If not feasible have a mechanism to monitor those email address and profile the incoming spam if any.
  5. Brand monitoring and domain registration – Organisation should be monitoring their brand mentions and/or any domain registration that can be used for phishing or a fraud or to launch attacks.
  6. Phishing is wildly used to lure users and entry points of malware. Organisations should also have a team looking for phishing sites and pro-actively perform takedowns.
  7. It is also ideal to share information of any attacks or compromise within peer industry to understand the possible exposure of an organisation.
  8. Understand your service providers and contractors as they can be a exploited to launch the attack.

Following points are few examples of what kind of information gets out or available that aids an attacker in launching the attack:

  1. It is important to know how your security controls are responding to inbound attacks. The information that they send back (for example a reconnaissance attempt) can also be used to map the network or understand type of device that is stopping adversaries. For example inbound scan blocked by firewall and responding with ICMP network unreachable message.
  2. Websites such as Google and Shodan can be used to collect lot of information about a target and therefore should be monitored. Especially accidental upload by internal employees. Eg – Employee uploading an excel sheet with organisation data on VT, just to make sure there is no malware. Pro-actively monitoring this can assist us to contact respective parties to take the data offline before entities with malicious intent get there hands on.

A Threat Intelligence and/or Hunting team must have this kind of approach. Organisations where there is budget limitation, can also engage their security operations or security service providers to perform these actions on their behalf. Frequency depends on organisations capability to invest in resources.

With this I will end part 1.

Finding Evidence of Data Exfil – USBStor artefacts

Readers!

Last year one of the member on SANS DFIR posted a question with regards to identifying whether there was any data leakage occurred in the environment via a USB thumb drive. As for the evidence investigator had USBStor artefacts. Shell bag analysis(TZ Works sbag) showed a large number of files touched (reg-UTC) within a very short time period and a few with the MRU (Most recently used list) flag set with different times.

This blog is a concise article of the tips provided by myself and other members. Provided tips assisted the investigator to support the theory of data leakage.

  1. Evaluating USB dates as a group.  If any number of artefacts is detected with the same exact time stamp, investigate it further. Having such artefacts indicates that they were somehow modified. It is also, worth the effort to carve the data for deleted registry files and look for relevant keys there.
  2. Normal users will/may access the files again after copying to any removable media to make sure the files were copied correctly and are not corrupted. This operation leaves shell items in the form of shell bags and link (.lnk) files. One can use Windows Time Rule to for evidence of file copy. Using the time rule examine the link files with target data pointing to files on removable media (tz works ‘lp’ is excellent for this). If the modified date of the target file data in the link file precedes the created date of the target file data in the link file, then this is an indication that the file was opened from the removable media, after the file was copied to the removable media. This means that even without access to the removable media, you can state that files were copied to the removable media and then they were opened from the removable media. The created date of the target data in the link file is when the file was copied to the removable media. One can state that the files were copied, but cannot state where the file was copied from, as that is not tracked.
  3. Now to determine when the file was opened from the removable media, look at the times of the link file itself. The created date of the link files will be the first time the file was opened and the modified date of the link file will be last time the file was opened. To discover the removable media, locate the volume serial number of the removable media’s file system which will be stored in the link file’s data. Correlate the volume serial number to the data from your USB drive analysis and you will get the manufacturers unique serial number for that removable media. Find that unique serial number across your enterprise and you will discover other machines where that drive was connected to. Correlate the link file target data to the shell bag data and you should be able to get a neat timeline of what happened on the system.
  4. Memory analysis of the system can assist. If the files were copied it should have data on the clipboard. Drag and drop will not likely have any artefacts.
  5. Registry hives –  one can use FTK registry viewer for ease. Usbstor have last written values – dates when the last device was accessed or connected.
  6. Look at the recent files in Windows section. Although if one is not able to open the file it may show which file from which volume – it may not prove that file was copied however if the document name is ‘organisationconfidential‘ than you can argue what was the file doing on USB? The link files should also contain volume serial that one can match/compare with removable media serials.
  7. Registry restore points can also be used to check last written dates.
  8. Look at the MFT records – they have sourceMFT and destinationMFT.

Tools mentioned : SBE – Shellbag Explorer and MFTparser

Links mentioned :

Click to access PlumbingtheDepthsShellBagsEricZimmerman.pdf

 

Threat Hunting and Pyramid of Pain

The buzz word first came in 2014 and individuals who were actually performing activities such as hunting for adversaries within network interested in Threat Hunting agreed with it on all aspects. During Threat Hunting and/or intelligence gathering or incident response we are mostly concentrating on identifying indicators of compromise and normally follow these steps:

  1. Collect Indicators of Compromise – Basic/Advanced Threat intelligence platform – Yes I have collected Indicators of compromise from all over world than what ?
  2. Compare the IOCs with internal logs – SIEM – to understand the extent of infection – lateral movements as we say. One can also use specific tools for this – carbon black, palantir, dark trace etc.
  3. Detect and mitigation – most of the time by running anti-virus and/or restoring the system from backup or re-installing a fresh copy.

Most organisation perform mentioned points believing that this is their Incident Response plan and threat hunting procedure, but they actually only performed 2-3 stages – Identification, Recovery and Follow-up/lesson learned.

This is somewhat I call as Reactive approach, as the name suggests incident response – responding to an incident. However, there is another approach -pro-active approach – where team of experience Incident Responders will look through the network and identify anomalies and/or unwanted entities within a network. Threat Hunting was it called. The days of external organisations notifying you of an infection or data exfil or their own data showing up on pastebin are increasing and organisation must have Threat Hunting and IR capabilities well invested and implemented. Proper Process and procedure are important as well in understanding how to perform these duties. Consider following:

Following is the pyramid of pain

pyramid of pain

http://detect-respond.blogspot.com.au/2013/03/the-pyramid-of-pain.html

The diagram has a scale that shows relationship between the indicators of compromise a Threat Hunter or an incident responder can find and how much pain it will cause to use them to detect the adversary.

Threat hunting and Incident response goes beyond just deploying a product within the network and responding based on what it alerts. It goes beyond normal rule and/or signature based mechanisms to detect threats that one cannot detect with just plug-n-play devices. Both requires human factor to perform these actions. Deep diving into the networks and looking for adversaries (active defense and/or pro-active investigations) is a must have within the organisation and Incident Responders and IT Team must work hand in hand. And don’t forget to involve Forensics. Yes, we need forensics to gather evidence properly.

Threat Hunting phases :

  1. Create and/or define Hypotheses
  2. Investigate via tools and techniques
  3. Identify new patterns and TTP (Tools, techniques and procedure)
  4. Inform and update analytics platform and/or database
  5. Start 1

It’s my pleasure to announce that I recently got honoured to co-author a book with Don Murdoch. The book will be used as a field guide and/or playbook for Threat hunters during Threat Hunting.

Happy Hunting !!!!

Hunting as an SOC analyst

Been security analyst in SOC for more than 3 years. Besides waiting for the alerts triggering from the device such as IPS or end point protection, one can write up rules in SIEM to analyse logs. SIEM needs to be constantly updated with new Intel. Below are few things that I look for for a customer during hunting remotely or on-site. Understand Incident response and threat hunting can be integrated.

  1. Central logging place such as SIEM logs from various network devices.
  2. Traffic violating security standards.
  3. Traffic going to or coming from countries where customer does not do business with.
  4. Access/running executables or confidential files on hosts/servers – this can be done by acceptable use monitoring.
  5. Threat intelligence and/or threat feeds – open source and subscribed and matching against the logs.
  6. Endpoint protection logs – especially the ones that are cleaned or quarantined. We need to understand how endpoint and/or AV vendors are identifying or logging these entries to get a broader picture and what type of tools or malware are being used against you.
  7. Publicly available information for the customer and analysing how that information can be used to target customers and monitoring those open doors.
  8. Windows logs – privilege escalation, failed attempts, user accounts on the system, which user logged into the system, what services/process running, one can also make list of folders that should not have any executables or services starting from.
  9. Proxy and/or DNS logs – suspicious packets, HTTP request, large/similar number of bytes in and bytes out, any traffic going via clear-text protocols such as 22. Look for specific keywords in DNS logs, also check what DNS servers requests are going – may find some foreign DNS.

To identify IOCs and/or malicious entities independent of any customer logs:

  1. Randomly accessing websites on top-level domains to identify any suspicious/malicious re-direction – the traffic is passed to the interface being monitored by snort. Windows machine will also have procmon with Virus Total integration and ofcourse wireshark.
  2. Analysing spam emails and run it over Security Onion to see if any alerts gets trigger. Extract domains and IP address and use them in the SIEM.
  3. Check specific parameters in the URL/HTTP requests that can be used to exploit web applications – although the IDPS may trigger the rule for it but there are instances where we do not get IDPS logs.
  4. Lastly, honeypot to identify bad actors.
  5. Lurking on private forums, IRC and dark web – hell yeah.
  6. Following threat campaigns.

Hope this helps. Happy hunting!!!!!!