Always A Bad Day For Adversaries

Tag: analysis Page 1 of 2

The Cost of Bad Threat Intelligence

There is no doubt that threat intelligence is now “a thing.” At RSA 2015 I couldn’t help but notice how many vendor booths were hawking their relevance to threat intelligence.  I hear about a threat intelligence start-up almost weekly.  That is not surprising given venture capital is flowing and C-suite customers are now investing in “threat intelligence.”  Everyone wants a piece of the pie.

While market growth for threat intelligence produces innovations it also produces negative by-products (welcome to capitalism).  The most concerning by-product is the reduction in threat intelligence quality.

A growing number of published threat intelligence reports contain inaccuracies and poor analysis.  A growing number of indicators across a variety of producers are either stale, irrelevant, or generate so many false positives to be useless.

What so many fail to realize is the cost of poor quality intelligence.  Here are some of the costs:

  • If a single threat intelligence-sourced alert generates $1000 worth of time to investigate a false positive, it is easy to see how that relatively small amount can multiple within an organization and across enterprises worldwide.
  • If an intelligence producer reports incorrectly categorizes a threat as APT (say instead of cyber crime) an organization’s security response to the threat will be (and should be) different likely involving a deeper investigation.  Again, this additional, and likely unnecessarily deep, investigation is costly in both time and resources.
  • Every poor quality report costs time to read and digest.  Time that could be spent understanding a high-quality report.
  • Every poor association or correlation derails an analytic effort at an organization.

Because organizational security resources are finite and already stretched thin these mistakes, errors, and poor practices consume critical resources which could be spent on other problems and reduces the security of an organization.

Two market elements have caused this quality reduction:

  • A need to garner attention in the growing cacophony of the threat intelligence market feeding a “first to publish” mentality which usually results in a “rush to publish.”
  • A lack of customer education resulting in a poor evaluation of providers thereby incentivizing the wrong aspects of threat intelligence – such as volume of indicators over their quality or relevance

Obviously, only threat intelligence providers can solve the problem, but what pressures can help drive effective change?  Here are some:

  • Threat intelligence customers armed with evaluation criteria (particularly quality metrics) which helps them leverage threat intelligence effectively without generating unnecessary costs – this will help create market drivers for higher quality
  • Industry must self-police bad intelligence by being honest with ourselves and each other.
  • Threat intelligence aggregation platforms should have quality assessment capabilities informing the intelligence consumer of potential problems (likewise they are also be in a position to highlight timely, relevant, and unique intelligence of great value)
  • Threat intelligence analysts trained in analytic tradecraft stressing quality and accepting an ethical duty

Security professionals practicing threat intelligence must understand the implications of mistakes and poor analysis.  Bad intelligence can and does decrease the security effectiveness of an organization. Therefore it is an ethical duty of the threat intelligence practitioner to reduce errors. Threat intelligence is difficult – intelligence by definition attempts to illuminate the unknown and works by making judgments with imperfect data – errors are natural to the domain.  But, with proper practices and procedures bad intelligence can, and must, be minimized.

15 Things Wrong with Today’s Threat Intelligence Reporting

What I think when I read most threat intelligence reporting

What I think when I read most threat intelligence reporting

As I have written before, intrusion analysis is equal parts knowing the technical elements of an intrusion and being an analyst.  However, most in this domain spend an inordinate amount of time studying technical details compared to honing any analytic skills.

How long has it been since you’ve taken a highly technical course?  (probably within the last year or two)  How about an analysis course?  (probably in the last 5 years, 10 years, never?)

I read several threat intelligence reports daily.  It is painfully obvious how the lack of analytic skill is harming the discipline. Many folks come from technical degree backgrounds and analyze packets and binaries well enough but can’t seem to tell the difference between inductive, deductive, or abductive reasoning.  Furthermore, their managers and mentors never recognize a problem, they just send them to more technical courses.

What is the risk?  Threat intelligence provides insight and context to improve decision making.  The risk of bad intelligence is high. Bad decisions can easily be made from poor intelligence – potentially doing more harm than good.  Good analytic practices improve analysis thereby decreasing the risk of poor intelligence.  You could have the best packet analysis skills in the world, but if you cannot communicate your conclusions effectively to those who need to act on your information those skills are effectively useless in threat intelligence.

We need to do better.  I started this post about a month ago and wrote down a “lesson” whenever I saw an example of poor analysis.  Needless to say, I saw some of these several times.  (Contrary to the recommendation of others, I will not cite/quote specific examples – I believe that would only name and shame others)

Trend – the word actually means something

How many times per week must I read about a new “trend” from threat intelligence?  One or two events does not constitute a trend.  Even three or more events, depending on the universe of events, may not constitute a trend.  Trends are serious.  True trends in adversary activity and methodologies inferred by threat intelligence should drive data collection, analytic tradecraft, and defensive decisions.  Before you start throwing out the word trend just because you’ve seen something a few times, consider the millions of other events you’re not seeing and consider if they’re just an anomaly rather than a trend.

Analysts and conclusions are like horses: sometimes you need to lead them to water

In many cases I can follow the logical progression of hypotheses and facts to the conclusion.  In some cases I cannot.  Either because an analyst failed to include the appropriate evidence/fact on which now an assumption must rest or because of convoluted logical reasoning.  Ensure evidence supports your conclusions and the logical reasoning is clear.  Don’t assume that what is clear in your mind will be clear in mine.

You can’t be completely confident all of the time – use words of estimative probability

Do you know how often I see the effective use of estimative probability in recent threat intelligence reporting?  Almost never.  This is a problem.  Not everything presented is irrefutable fact; in fact, a good analysis will have a proper mix of data/fact, hypotheses and conclusions.  The confidence values of these conclusions vary.  When you don’t effectively apply estimative probability and variable measures of confidence it removes value from the analysis and increases the risk of poor decision making by consumers.  First, if you don’t know what estimative probability is, LEARN about it.  Then learn how and when to apply it properly. Importantly, also know what words/phrases to avoid (i.e. weasel words).

Never be afraid to include contrary evidence

Do you know how many times I saw evidence contrary to the conclusion presented in a threat intelligence report this month?  Never.  Practice analytic honesty.  If there is exculpatory evidence, contrary evidence, or an alternative hypothesis – show it.  As long as you’re following some of the other lessons here (e.g., separating fact and hypothesis, using words of estimative probability) it will strengthen your analysis and provide more value to the consumer.

Just because you’ve seen something for the first time doesn’t mean it’s the first time it happened

We all love finding something awesome and telling the world.  It’s cool because we all want to know what you’ve found!  But, please don’t assume it is the first time it has happened or even the first time it has been seen.  Having confidence is critical, but hubris is deadly to analysis.

Don’t operate on an island

You are not alone!  Don’t act like it.  Share and consume, enrich and enhance.  Go ahead and build on the analysis of others (citing appropriately).  Whatever your observation point or data sources, they’re not omnipresent.  I rarely see analysis reference other (obviously) related pieces.  How is that?  The power of defenders lies in our community and our ability to work together against an adversary.

Be bold, but don’t be stupid

I like my analysis like I like my coffee: bold.  But, there is a line between taking facts to their logical conclusion and taking facts to crazy-land.  The difference is logic.  Ensure your conclusions and hypotheses follow logically from the facts through induction, deduction, or abduction.  If your conclusions cannot be logically traced or tested, then they’re likely living in crazy-land.

Don’t mix hypotheses, conclusions, and facts

Hypotheses, conclusions, and facts are not the same.  Your intelligence reports should not treat them as such.  Ensure that your readers can effectively separate the three through your use of language, formatting, etc.  When the three are confused it can lead to erroneous assumptions by consumers and lead to decisions made on weak conclusions rather than facts.

Save hyperbole for the glossy promotion material

Hyperbole has its place.  It doesn’t have a place in threat intelligence.  Save that for the glossies.  Be precise, honest, and accurate.  Don’t embellish or exaggerate.  Trust me when I say we have enough people running around like chickens with their heads cut off in this field.

Logical fallacies are just that, get to know them

Enough said.  I’m sorry I have to say this, but please understand the differences and applicability of deductive, inductive, and abductive reasoning BEFORE writing your first threat intelligence report.  Or, at the very least, have an editor who knows the difference.

Don’t create new words when existing words suffice

I’m not going to name-call here.  You know who you are.  There are times when words/phrases have multiple meanings.  I understand that.  But, aside from that….stop it.

Tell a story!

Your analysis is a story.  You’re effectively documenting history – studying the past – in the hopes of making conclusions and judgments which will help the present and future.  While you are documenting the activity of computers you are ultimately describing the actions caused by adversaries.  Just like any story your report should have a beginning, middle, and an end.

Answer my questions

Write as if you are in a conversation.  Think about what somebody else may ask of what you’re saying, and address those questions in the text.  Any questions left unanswered have the ability to form into assumptions on the part of the consumer/customer.  If you don’t have an answer, feel free to write: no further information.

Be concise, be accurate

Practice analytic honesty and respect the time of your reader.  The report you’re considering may actually need to be three different reports – one describing all of the malware reverse engineering, one describing all of the network activity, and another describing the threat itself which references the other report.  Putting everything in one report does not make it more consumable, it makes it less consumable and allows analysts to muddle up various lines of analysis.

Describe diagrams, charts, and tables both in the narrative text but also in a caption

This is just a pet-peeve of mine, but one which I find increases the readability of threat intelligence reports.  Make sure you describe your diagrams, charts, and tables in both the narrative text (as part of the story) and also in a caption.  I find this necessary because as I move backwards and forwards through a report reading and re-reading, forming and re-forming logical chains, I don’t want to hunt for the description in the text every time.  I also don’t want to jump to the caption in the middle of text if not necessary which breaks my concentration.

Snakes and Ladders: How Intrusion Analysis and Incident Response is Like a Board Game and the Critical Role of Pivoting

Pivoting is, in my humble opinion, the most important skill of intrusion analysis and incident response.  I have been teaching/training/mentoring intrusion analysts for over 7 years.  In my experience, this is the most difficult skill to train as it requires creativity, attention to detail, and a full knowledge of their data sources and how to exploit those.

Pivoting is the ability to identify a critical piece of information and being able to maximally exploit that information across all of your sources to substantially increase your knowledge of the adversary and further identify the next critical piece of information – which is then pivoted upon moving you deeper into the operation of the adversary – hopefully earlier into the kill-chain.

An example: trolling through log files you discover a very odd HTTP user-agent accessing your website.  You then query on this user-agent across all the log entries and identify a significant number of users providing this string value.  (Pivot on user-agent) You then extract all of those particular log entries and identify a regular time pattern of access indicating automated functionality.  You also discover that all the requests have a very odd resource/page request – bob.php.  (Pivot on bob.php) You then take that page name (bob.php) and examine all HTTP traffic in your network over the last 2 days and discover that several hosts in your network have been POSTing odd data to bob.php….at this point you may retrieve and conduct a forensic analysis on the hosts, etc.  When you finally discover that the adversary has compromised several internal hosts and has had them HTTP POSTing data to a webpage on your external-facing website of which the adversary then uses to extract the information/data.  At this point, you now have several pieces of mitigative value: the source IP of the adversary’s infrastructure on the outside, the page deposited on your website, any malicious tools discovered on the hosts, the HTTP traffic, etc.  All of which are collectively more valuable to defense than any one of those pieces of information independently.

 

A Step Function

In this way, analysis and incident response is a step-function.  Most of the time analysis is, in a sense, rote.  It involves looking through log files, examining and validating alerts, looking at various binaries.  Step by step peeling back the onion of the adversary’s operations.  At times we even move backwards as an analyst makes an incorrect assumption or a poor hypothesis which costs time/money/resources to recover and correct the analytic path.  However, when a piece of critical information is discovered it should be exploited and a deeper knowledge should be achieved moving the analysis to a “new level” of the function substantially increasing the knowledge as a whole – which, in theory, should lead to additional mitigative opportunities.

 

Chutes and Ladders

My favorite analogy is that of the game of “Chutes and Ladders” (or “Snakes and Ladders” for those outside the US).  A player slowly moves across the board block-by-block but then happens on a ladder which moves them up substantially in the board.  Other times, they land on a snake/chute which then brings them back down.  This is the process of analysis.

Why does this matter?  It matters because this understanding can help us better understand the process and model of analysis thereby providing an opportunity for researchers to target parts of analysis to increase the chances/likelihood of a step-function increase in knowledge and decrease the chance of a decrease.

One way is to increase the capability of analytic tools to maximize pivoting.  Allowing for an easy and quick way to query other data sources with a new discovery and integrating that into the analytic picture.  The tools should also allow an analyst to ‘back-up’ their analysis removing a possible poor path once an error is discovered.

This is just a couple of ideas.  I’d love to hear yours.

How I Work To Music and 15 Songs I Work With

I love to work to music.  I almost don’t even care to what genre or song I’m listening.  Of course, music is a highly personal choice.

While sometimes I listen to Pandora or another Internet radio station for variety, I also have a selection of my favorite albums at hand which I pick out like tools depending on my mood and my current task.

Here are three of my most common tasks and 5 songs that I associate with that task.

Authoring/Writing:

Jack Johnson –  I wrote almost my entire thesis to his early albums in a coffee shop.

 

 

 

 

Programming:

Weezer – Their entire Blue and Green albums have led me through over 150,000 lines of code successfully

 

 

 

 

 

[Honorable Mention]

Analysis:

 

 

 

 

 

15 Knowledge Areas and Skills for Cyber Analysts and Operators

Rodin’s The Thinker

 

Here are some knowledge areas which I consider necessary to conduct effective intrusion analysis and operations. In future articles I will go into further details on how to improve your skills in each of these areas (and link them from here). The knowledge areas are not listed in any particular order.

Every organization’s mission, focus, and needs are different and therefore I don’t pretend to define the ‘perfect’ analyst for any mission.

Critical Thinking and Logic

I will be forthright and say that I consider this skill the most important above all others.  It is a gateway skill which allows an analyst to become proficient in many others.  It is also the skill upon which I rely for analysts to temper their judgments and make the best decision as to how to approach a problem.  Logic is complementary to critical thinking and the two cannot be separated.  Without a proper foundation in logic critical thinking is ineffective.

US-CERT Incident Reponse Report

Critical Reading and Writing

Critical reading is being able to dissect the text of a document to extract the most important information and apply critical thinking skills to the information.Effective/Critical writing and documentation refers to writing correctly, logically, concisely, and effectively for your audience (which likely includes yourself).  Most importantly, write in an organized manner to help others use their critical thinking skills.

History

As I have said previously: “Study History.  It provides perspective.”  Works like The Cuckoos Egg are a great start; but branch into other areas: military history, biographies of famous leaders, studies of famous events.  Learn how others have been able to assess strategic situations, derive tactics, and evolve their strategy to a quickly changing situation.  All of these skills are useful in intrusion analysis and incident response.  Be able to step back from a situation and apply the lessons learned from others to your own.

Research Methods

In the cyber security domain we face more unknown than knowns.  My favorite saying is “no analyst is an island” meaning that there is nobody who knows it all and we need to rely on others and the greater community to help to solve problems.  Therefore, a significant skill is the ability to conduct effective research on hard problems to find existing solutions – preventing, as the saying goes, “recreating the wheel.”   This skill, more than any other, will increase your effectiveness and efficiency.

This skill can and should be mixed with other skills described – critical reading to get through research material quicker, critical thinking to see through the B.S. and FUD, and effective writing to document your findings so you use it again in the future.

Analytic Approaches and Methods

When facing any problem, being able to identify and evaluate the various approaches to solving the problem is invaluable – some would say critical.  Being knowledgeable in as many analytic approaches as possible is invaluable, and being able to create new approaches on-the-fly is even more invaluable.

Learn analytic methods from others.  Look for their mixture of logic, research, tool use, and lines of critical thinking and apply them yourself.

Network Protocol Map

Network Protocol Map

Network Protocol Analysis

Know your network protocols.  More importantly, be able to research, analyze, and identify new or previously unknown protocols.  Don’t be afraid of packets.  Use your research methods and critical reading skills to dissect protocol definitions and RFCs.

 

Programming

A basic knowledge and ability to write computer programs is very useful in that it practices logic skills, helps one better dissect cyber security activities, and allows one to create and/or modify tools quickly as necessary.

Psychology

An understanding of the fundamental theorems of psychology is useful when attempting to determine the intent, context, and motivations of an adversary.  For example, knowing and being able to apply the fundamentals of Maslow’s Hierarchy of Needs or Operant Conditioning will go towards influencing your adversary through operations to achieve a positive outcome and better protect your network.

See Also: A Hacker’s Hierarchy of Operational Needs based on Maslow’s Theory of Human Motivation

Hacker Tools and Methodology

Obviously, a working knowledge of hacker tools and methodologies is a must.

Binary Reverse Engineering

IDA Pro Binary Reverse Engineering

IDA Pro Binary Reverse Engineering

All hackers use capabilities and tools to achieve their desired effects.  Most of these are binaries either live on command-and-control nodes or are delivered to the target for operations.  Having a working knowledge and ability to reverse engineer a binary is necessary to conducting effective analysis   Even if your organization has dedicated reverse engineers having this knowledge to effectively communicate and ask intelligent questions of these engineers is just as important.

Host-Based Log File and Forensic Analysis

Understanding the internal workings of a host and operating system help not only in investigations where host data is available but also as a learning tool to understand the adversary’s target environment.  This will further inform the analyst by providing greater context to the choices of an adversary given the host environment.

This knowledge should be coupled with that of hacker tools and methodologies and network and host configuration and administration for full effect.

Network and Host Configuration and Administration

As I’ve said in another post, 5 Intrusion Analysis Ideas in 10 Minutes, I believe that cyber security professional should be just as proficient in understanding how networks and hosts are administrated and configured as in how those systems are attacked.

Signature Writing and Detection Tools

Snort Rule Header

Example Snort Rule

Finding malicious activity on your network is important, being able to track that activity and detect when it returns is an imperative.  Therefore, analysts and operators should be proficient in their organization’s particular signature and detection tools and learn how to author the best signatures.

It is just as important to understand how a detection tool works but also it’s biases and limitations – so you know when there are potential false positives and false negatives.  This is one of my 20 Questions for an Intrusion Analyst.

Incident Response Methodology

Incident response methodology is obviously a requirement for anybody who is part of the incident response team in their organization.  However, incident response should be well-known by every intrusion analyst.  This is simply because they will likely be generating documentation and analysis for the incident response team.  The better they understand the methodology, the better they can tailor their documentation and feedback to the needs of response and mitigation.

Tools

Wireshark

Wireshark

I am fond of saying, “there is no one tool to rule them all,” meaning no single tool will do everything you need. While I think that too much time is spent by cyber security professionals in becoming proficient in a specific tool-set, I cannot under estimate the criticality of these tools to our profession.  However, I believe that over reliance on our tools breeds ignorance of the data the tool is processing and analysts become unwilling to challenge and blindly trusting the output.

Therefore, it is important to know how to operate and understand the tools that are best for your mission be it OllyDbg or Wireshark.

Lastly, with a strong or competent programming background, as described previously, you are empowered to write your own tools or improve existing tools for the benefit of the community.

The Science of Intrusion Analysis and Incident Response: Introduction

[important]This is the first of several posts in a series expanding on how to turn intrusion analysis into a science.  Subscribe to the blog via email, follow us on twitter or like us on Facebook to keep-up!  [/important]

Previously I wrote about the Art of Intrusion Analysis and how I thought that Michelangelo’s quote was the best representation of how intrusion analysts arrive at knowledge.

However, my concern is not to document the art of Intrusion Analysis or Incident Response, but rather to transform the art into a science.  What does that mean?  What is the science of intrusion analysis and incident response?

First, we must define science (there are many definitions, this one will suffice for our purposes).

Science (from Latinscientia, meaning “knowledge”) is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe. — Wikipedia

Second, how will we know when intrusion analysis and incident response have become a science?  Aristotle can give us the answer.

[A] man knows a thing scientifically when he possesses a conviction arrived at in a certain way, and when the first principles on which that conviction rests are known to him with certainty—for unless he is more certain of his first principles than of the conclusion drawn from them he will only possess the knowledge in question accidentally.  — Aristotle (384 BC – 322 BC) in Nicomachean Ethics

From this I draw the following requirements to make intrusion analysis and incident response into a science:

  1. Intrusion Analysis and Incident Response must be systematic
  2. There must be first principles upon which hypotheses and predictions can be drawn and tested with experimentation
  3. There must be an organizing function to build knowledge
  4. There must be a set of theories which are generally accepted, testable, and repeatable following from first principles and hypotheses

Why do we care if Intrusion Analysis is a science or not?  An intrusion analysis and incident response science means less duplication of effort solving the same problems and a more cohesive approach to improving tools, tradecraft, and training.

Thanks to Richard (@taosecurity and Tao Security Blog) for the unanticipated use of his image! 🙂

 

20 Questions for an Intrusion Analyst

There are many approaches to finding the right people with the right talent to solve problems.  Intrusion analysis and incident response is no different.

I recently saw a great recruiting quiz to test potential employees in various knowledge areas which included programming, packet analysis, protocol analysis, snort rule writing, reverse engineering, data encoding, advanced mathematics, and other topics.  The test was designed so that it crossed so many topics one person would likely not successfully complete it.  However, it would highlight a person’s strengths and interests to give the assessor a more complete picture of the applicant.

This made me think, what topics and questions would I use to achieve the same effect?   After some deliberation, I have developed my own “20 Questions for an Intrusion Analyst” recruitment quiz (below) to highlight areas I think are important about a potential analyst joining a team.

As you may notice, I have covered several areas with these questions: analytic reasoning, creativity, adversary operations, packet analysis, intrusion detection, programming, reverse engineering, vulnerability analysis, exploit writing, and teaming.

I am purposefully not providing the answers 🙂

20 Questions for an Intrusion Analyst

  1. Describe you first experience with a computer or network threat
  2. You are given 500 pieces of straw and told that one piece is a needle which looks like straw.  How would you find the needle?  What other pieces of information would you like to have?
  3. Explain the difference between intrusion and extrusion detection
  4. Describe an adversary pivot, give an example, and explain its importance to intrusion analysis.
  5. Describe your analytic biases.
  6. Use the bit string 1101 to answer the following questions:
    1. The bit string when XORed with 0
    2. The decimal value of the string
    3. The string represented in hexadecimal
    4. Does this represent a printable ASCII character?  If so, which character?
  1. What is your favorite intrusion detection system?  What are its biases and limitations?
  2. Circle any of the following films you have seen: Hackers, War Games, Sneakers, Tron
  3. Describe a method to find an intruder using only network flow data (no content).
  4. Explain insertion and evasion of intrusion detection systems.  Give an example.
  5. Describe the activity detected by the following Snort rule.  What could be done to make the rule more effective?   alert icmp $EXTERNAL_NET any <> $HOME_NET any (msg: “activity alert!”; sid:10000011; content:”MZ”;)
  6. Write a code snippet to sort the following data by the first column
10,bob
8,sally
2,suzy
3,billy
5,joey
  1. How much time/week do you spend on your own researching computer security/threat topics?  What sources do you use to maintain situational awareness on threats in the wild?
  2. What will the following code print out?  Is there a vulnerability in the code?  If so, describe the vulnerability and a potential method of exploitation.
#include
#include
int main(int argc, char *argv[])
{
   char string[40];
   strcpy(string, argv[1]);
   printf("The message was: %s\n", string);
   printf("Program completed normally!\n\n");
   return 0;
}
  1. Describe and explain any “interesting” entries in the netstat log:
Proto Local Address     Foreign Address    State
 TCP  0.0.0.0:53        0.0.0.0:0          LISTENING
 TCP  0.0.0.0:135       0.0.0.0:0          LISTENING
 TCP  0.0.0.0:445       0.0.0.0:0          LISTENING
 TCP  0.0.0.0:5357      0.0.0.0:0          LISTENING
 TCP  192.168.1.4:53    91.198.117.247:443 CLOSE_WAIT
 TCP  192.168.1.4:59393 74.125.224.39:443  ESTABLISHED
 TCP  192.168.1.4:59515 208.50.77.89:80    ESTABLISHED
 TCP  192.168.1.4:59518 69.171.227.67:443  ESTABLISHED
 TCP  192.168.1.4:59522 96.16.53.227:443   ESTABLISHED
 TCP  192.168.1.4:59523 96.16.53.227:443   ESTABLISHED
 TCP  192.168.1.4:53    208.71.44.30:80    ESTABLISHED
 TCP  192.168.1.4:59538 74.125.224.98:80   ESTABLISHED
 TCP  192.168.1.4:59539 74.125.224.98:80   ESTABLISHED
  1. A host sends out an ICMP ECHO REPLY packet.  List all of your hypotheses to explain this activity.
  2. Describe the protocol stack of the following packet and the payload. Is the packet legitimate? Why or why not?
0000  00 00 c0 9f a0 97 00 a0 cc 3b bf fa 08 00 45 10   .........;....E.
0010  00 89 46 44 40 00 40 06 72 c7 c0 a8 00 02 c0 a8   ..FD@.@.r.......
0020  00 01 06 0e 00 17 99 c5 a1 54 17 f1 63 84 80 18   .........T..c...
0030  7d 78 cc 93 00 00 01 01 08 0a 00 9c 27 34 00 25   }x..........'4.%
0040  a6 2c ff fa 20 00 39 36 30 30 2c 39 36 30 30 ff   .,.. .9600,9600.
0050  f0 ff fa 23 00 62 61 6d 2e 7a 69 6e 67 2e 6f 72   ...#.bam.zing.or
0060  67 3a 30 2e 30 ff f0 ff fa 27 00 00 44 49 53 50   g:0.0....'..DISP
0070  4c 41 59 01 62 61 6d 2e 7a 69 6e 67 2e 6f 72 67   LAY.bam.zing.org
0080  3a 30 2e 30 ff f0 ff fa 18 00 78 74 65 72 6d 2d   :0.0......xterm-
0090  63 6f 6c 6f 72 ff f0                              color..
  1. What type of encoding is used in this example: aGVsbG8gd29ybGQNCg==
  2. Who do you turn to most on technical questions?

You didn’t expect the 20th question to be here did you?  You should expect the unexpected by now.

Hacker Motivations or Hackers Need To Eat Too

New research appears to raise questions over the conventional wisdom that pure nation-state cyberspies rarely, if ever, dabble in traditional financial cybercrime.  –  “Cybercriminal By Day, Cyber Spy By Night?” in Dark Reading on 1 March 2012

Dark Reading (@darkreading) wrote from the RSA 2012 conference of an intriguing analytic correlation made by the Dell SecureWorks Counter Threat Unit between the RSA attackers and cyber financial crimes.

The article is interesting in two ways.  First, it showcases some good analytic tradecraft correlating seemingly independent activities through adversary personas and infrastructure (in this case domain name registration).  Second, it asks the question: can a hacker be both a spy and cyber criminal?

The fact that an adversary will be using their skills for two purposes supposedly challenges “conventional wisdom.”  Normally, intrusion analysts work towards identifying the motivation of the hacker/attacker to gauge the best response (hopefully) and potentially offer clues to attribution.  There are many “conventional” terms we use to describe “hacker motivations”: script kiddies, espionage, hacktivism, black/white hat, etc. (see McAfee’s 7 Types of Hacker Motivations).

However, we often look too much towards our technical understanding and fail to acknowledge basic human motivations: safety, physiological needs (water, shelter, food, etc), love, esteem, and self-actualization [see “A Theory of Human Motivation” by Abraham Maslow or a summary of Motivations on Wikipedia].

Hackers, as all humans, are not above the basic motivations which include greed.  This would be a very simple hypothesis of why a cyber espionage actor would turn to cyber crime – for financial gain.  Maybe they were not being paid enough in their espionage job and “honeymoon” as cyber criminals, or they were simply contractors to multiple customers (a state vs. a criminal organization).  Money is a highly motivating factor.

I use the case of the “Wiley Hacker” by Cliff Stoll (on the Reading List) while teaching to highlight that a hacker working day-in-and-day-out needs to eat, live, and provide for the most basic human motivations.  Therefore, it is perfectly reasonable to ask: if they are hacking all day/every day, how are they providing for these motivations?  Is somebody paying them to hack?  Are they living in their parents’ basement?  Do they have a trust fund?  All of these are perfectly reasonable hypotheses with varying degrees of likelihood.  But they all lead to other questions of attribution and higher motivation.

If, in fact, “conventional wisdom” is that espionage actors are not motivated by money to use their skills in other endeavors, an even more fundamental understanding of human motivation contradicts that wisdom.  “Conventional wisdom” is simply another term for analytic assumption and this again highlights that analytic assumptions easily cloud judgement.

The Art of Intrusion Analysis and Incident Response

“In every block of marble I see a statue as plain as though it stood before me, shaped and perfect in attitude and action. I have only to hew away the rough walls that imprison the lovely apparition to reveal it to the other eyes as mine see it.”  Michelangelo (1476-1564)

Michelanglo was once asked how he came to carve such a beautiful statue of an Angel in the Basilica of San Domenico. His response is seen above.

I have many times expressed that intrusion analysis and incident response is more art than science.  Expertise lies with experience rather than book knowledge and gut instinct is invaluable and as likely correct as an educated guess.

I then wondered: if Intrusion Analysis is an art, to which art should it compared?

I recalled this, one of my favorite artistic quotes, and how aptly it applies to the domain of intrusion discovery and analysis.

In many ways, the answers we analysts seek is in the data.  It only requires us to “hew away the rough walls” of the unimportant data revealing the activity of interest.

I teach many new analysts that to find the new and unknown you must distinguish the old and known, remove that, and you are left with what you are seeking.

Analysts Should Expect the Unexpected

Diocyde tweeted a good but older (2009) article about hiding malicious executable code (malware) in the Windows Registry: Malware IN the Registry a.k.a. if it can’t be Done, Why Am I Looking At it?

The post is a good description of what almost all incident responders/intrusion analysts encounter regularly: Is that right?  How could that be?  Hey [analyst sitting in the next cubicle] is this what I think it is?

After 9 years of intrusion analysis in various organizations, I can say that this happens to me very regularly.  Now, I expect the unexpected.  Not much surprises me any longer.

However, it is fun to watch a new analyst come upon these things and me, nonchalantly, describe what they are seeing and how cool it is.  They are always astonished at the tactics of the adversaries and the lengths to which they will go.

While we should always expect the unexpected, we should never lose our respect for the adversary and their ability to find new ways to astound and confound us.  For when we lose that, we blind ourselves.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén