CHRIME and Reputation



No one lives in a vacuum.  Just like the process of living leaves artifacts that point to history, so do the same events leave behind a trail of impacts, of evaluations that we clump together to call reputation.  Reputation is the “R” in CHRIME and a key factor in evaluating an event, element or concept.  An element of DNS with a negative reputation of infecting users with malware is pretty indicative, potentially enough to tip our decision point in the right direction.  The same applies for an IP Address flagged constantly for scanning, a file name that implies forbidden content or an adversary who penetrates security on a regular basis.  Nothing instills more fear in management than the proof that a known malicious group is targeting them.


The eye of the beholder

Sans running into a multi-eyed orb of doom in a gaming session, knowing how others view the element, event, or action you are evaluating with CHRIME is important.  This is more artfully done by example than in any other way, so I’m going to fall back on our phishing scenario to illustrate the logic.  Equally, while on the topic, logic is the underpinning of this check, even though you’ll slam into a lot of different emotion when defining reputation.  In the phishing event, we received a widespread phishing email against dozens of people in the enterprise.  It led to a website and domain mimicking the company’s with the aim to steal credentials.  It also wasn’t stand-alone, but one in series of attacks focused on the company.  Before digging in on reputation, it helps to have the targets.  Taking the data from above, we would organize it using the same word pattern technique we discussed in the Constellations topic.  A sample of what might look like is as follows (condensed version):

  • Email
    • Link
    • Sender
    • MTA chain
    • Attributes
    • Message (preamble, call to action, close)
  • Targets
    • Internal details (department, authority, title, etc.)
    • Insider or threat data
  • Mimicking website
    • Content (where stolen, how much, etc.)
    • Artifacts
    • Communication
  • Server or address accepting stolen credentials
    • Recipient information
    • What was sent (packaged content)


Reputation then starts with this list.  What follows from here is your rubric, or measurement stick.  It’s a series of questions that help orient you to the data.  Here are some examples:

  • Does evaluation information exist on any of these elements?
    • Step one is always an internal check.
      • Have we seen this before and rated it negatively or positively? This can make forming a determination pretty quick if you already have some insight.  In the phishing above, perhaps we have brushed against one of the MTA in the received chain and recorded it as a commonly spoofed MTA seen in past phishing.  That’s an easy negative reputation correlation.  Consider the targeting.  If you are seeing, internally, the same targets being put into focus by phishing, that too is a signal towards reputation.
    • Appropriately, the second step is external. Be like the Roman god Janus and look inward and outward simultaneously.  If external reputation rating on the element examined exists, incorporate it into your analysis.  Information sharing collectives serve well in this capacity, as do reputation sources like Alienvault’s OTX or IBM’s online exchange.
  • Comments by humans are critical signals of attention. Positive or negative content online about the event, element or concept evaluated with CHRIME can provide insight into reputation.  Again, always start internal and then check externally.  After all, you are your most trusted source.


Determining reputation means creating a set of observations you can iterate over.  Correlation does not mean causation.  Even if every shred of evidence points to what you are evaluating as negative, it doesn’t necessarily mean it’s true.  It’s a damn huge hint towards that being the truth, but it’s not 100%.  Correlations have to be determined as accurate and then causation links systematically explored via as large a possible set as can be managed.


Where’s the speed…?

The point of CHRIME is efficiency and speed.  Running the above can take a ton of time, especially to perform accurately.  That’s why you leverage a 2R approach: first Rough and then Refined.  Going in rough means only getting a potentially low confidence reputation evaluation.  Reputation is wedged between Intent and History, so it can not only support them, but also be supported in return.  That keeps it from being a bad determinant as these two concepts need to align or the Reputation step requires more work.  For a single-tier, first-pass use of CHRIME, that can be all you need.


It’s all in the logic

I want to take a second to make sure and encourage you to express care employing this type of logic.  As threat analysts, we employ a certain amount of syllogism in our logic.  Categorical syllogism is pretty commonplace.  Example:


Major Premise:  Malware A is only used by the Fire threat actor

Minor Premise:  We were attacked with Malware A

Conclusion:     We were attacked by the Fire threat actor


The amount of finger pointing at a group discussed in a report that I have seen using this logic could fill enough buckets to circle the earth.  There is nothing wrong with syllogism, but you have to make sure your logic is sound and the conclusion follows logically from the premises. Otherwise, you run the risk of committing a logical fallacy, like an association fallacy.  The above categorical syllogism, for example, is a form of guilty by association fallacy.  It can only be true if you clearly show Malware A is truly used solely by the Fire threat actor, something exceedingly difficult to show as true.  I could have just as easily said:  Jim wears a t-shirt that says, “hack naked”.  Only hackers wear t-shirts that have the word hack in them.  Therefore, Jim is a hacker.  This kind of guilt by association is incorrect.


The same follows for the ad hominem version.  Example:  The shadow brokers thanked NSA for letting them steal exploits and tools that were incorporated into malware—asserting that the NSA is “bad” agent and responsible for the misconduct and damage from the malware is exactly the type of ad hominem version of guilt by association.  It’s evocative and emotionally appealing, but not necessarily correct.


Always, and I’ll say it again, always make assumptions checks and then follow with an identical check to make sure you haven’t fallen into a logical fallacy.  Reputation is a soft, but critical element of CHRIME.  It’s rarely enough to stand alone, but can be a powerful influencer of the other topics.


We also use CHRIME in our daily work and you can find me talking about it at ISSA and conferences pretty year round.  In fact, Cyberdefenses believes in this technique so much that we have a full-day dedicated training course to it.  You can find about our offerings on CHRIME and other via this link:


This also ends the 3rd discussion on the History component of CHRIME.  If you missed the other articles on CHRIME in this series, you can find the introduction, 1st, and 2nd articles here.

About the author

Monty St John

Monty is a security professional with more than two decades of experience in threat intelligence, digital forensics, malware analytics, quality services, software engineering, development, IT/informatics, project management and training. He is an ISO 17025 laboratory auditor and assessor, reviewing and auditing 40+ laboratories. Monty is also a game designer and publisher who has authored more than 24 products and 35 editorial works.