CHRIME and Malware

CyberDefenses - M is for Malware

Malware, the scourge of our existence as cyber threat intelligence.  It’s the last thing we want to detect in our network and a strong part of our enemy’s arsenal.  In fact, commonly when I’m teaching students about malware in our Introduction to Threat Intelligence class, I explain to them that malware is like a firearm.  Many different types exist, as varied as human ingenuity.  However, while their application is diverse, in use they are pretty singular.  You may wield a firearm as a deterrent, as a threat, or as a means to employ violence — these are application of the firearm — but, at the end of the day, their use is to inflict damage; mainly via a projectile expelled at great force.  Firearms are crafted to kill.  That is their ultimate use and the point behind their creation.  Malware follows suit.  Its application is diverse, but it’s usage is simple — it also inflicts damage.  Malware is crafted to do one thing, either directly or indirectly, and that is to compromise.  Like Jessica Rabbit said in Who Framed Roger Rabbit, “I’m not bad, I’m just drawn that way.”  Malware is crafted to break the rules, to avoid the protections, and circumvent security.  It could be a backdoor, ransomware that steals data, a keylogger or many dozens of other applications.  It is, as I mentioned previously, what plagues us and it does so successfully because of our nature — what we do and how we do it— as well as our view on its danger.  It might not get infected, we frequently think, after all — what do we have that they might want or are we not too small for them to care?  The thought that obscurity, perceived value or size is enough to deter an attack is a compelling argument, but utterly flawed.  I’m digressing a bit from CHRIME, but these are a trifling number of the reasons why Malware is the “M” in CHRIME.  I want you to think of malware as a switch.  When it’s present, the “M” in CHRIME is on.  When it’s not, it’s out of play.  The question is always asked, however, and continuously re-examined until the decision is made.


Breaking up the thoughts in your mind

Malware, even if you handle it well in an incident, is a game changer.  Its very presence in your infrastructure sends a wave through your security apparatus and leadership.  A small wave will lap on the shores of your department and go no farther.  A big wave will swamp your station and sweep up over the heights of your corporate leadership and potentially drown the great mass of your employees.  It sounds alarmist and oversimplified to say, but I’ll happily point out some examples from recent months to illustrate.  Let’s talk about Qbot (or Qakbot).  It’s an unhappy day when you get malware and Qbot loves to steal credentials and spread around to your network shares to continue to propagate.  It’s pretty well known, highly documented, and with a good response not an incident you have to go all “hammer and tongs” to clean up, not that it can’t take you to your knees if you are not prepared or speedy enough.  It won’t make the rounds upstairs to darken your day or send your employees to twitter to squawk about how much your security sucks where they work unless it does catch you not minding the monitors.  Ransomware has the same angle — proper controls in place it doesn’t shut off the lights.  Give it at chance to take root and spread, or have a NotPetya situation where its coming in via a protected pathway, and it’s going to have every person in the C-suite and trustees/investors breathing down your neck.  Hit hard enough and the flood to social media to pile up the excrement could become legendary.  Not that it has to be ransomware.  Take Target, for example.  It was point of sale (POS) malware that did them in and years later, they are still paying for that breech, both monetarily and in loss of reputation.  It’s a chilling thought to contemplate.  Thankfully, that’s why you have a security team to dream up those scenarios that could damage or destroy your company and work to make sure they don’t happen, by purpose or accident.



The devil is in the details…

Remember where I mentioned that malware is like a firearm a bit earlier?  It’s important to keep that in mind.  Take a picture of a firearm and put it in mind.  Now, let me guess, it was a handgun, right?  …No?  How about a rifle?  I’m sure, even if either of those missed, with a little elbow grease I could guess what broad category of firearm you are picturing.  We do this same type of classifying when we look at malware.  Just like with firearms, the size, shape, and attributes of the malware tell you about it in broad strokes.  It’s how we say a particular malware is a data stealer, backdoor, Trojan, and all the other interesting labels we adorn malware.  Not just the class or group in broad strokes, but deep into details to really speak to capacity too.  In firearms, we might speak to barrel length, magazine capacity, sights, balance; whether it’s automatic, semi-automatic, and so on.  We delve into the same details with malware.  Like firearms, malware is named.  You might look at a handgun and say, “this is a Colt” or a rifle and say, “this is a Remington”.  In security, we look at malware downloaded to your computer and say, “this is Qakbot” or find during our threat hunting activity a backdoor and say, “this is Derusbi”.  In CHRIME, the “M” is where you determine if the target of your analysis is malware, and if so, sketch out descriptive terms for the function, organization, communication, and composition of the malware.  At a minimum, rough capacity in each of the four areas should be outlined.  A fast sketch, with likely need for deeper detail should be attained to help understand the level of menace or hazard represented by the malware.  Malware that beacons out on a heartbeat is, in every right, a hazard.  Malware that drops other files, is highly armored, communicates and exfiltrates data, and has keylogger and identity stealing capability is another threat altogether.  The capability to outline that information, even if you must label it unknown or low-confidence is critical to correct decision making.  In intelligence, especially threat intelligence, analysis techniques must support building the picture of information into intelligence that can facilitate decision making, otherwise it’s failing.  It is not just information gathering to build information, it is to craft a clear enough sight picture to enable decision making.


Who owns this malware anyway?

Hearkening back to firearms, if you find one in your back yard, who owns it?  Could you go by the serial number stamped on it when manufactured?  How would you use that?  Do you need a storehouse of records to access to see if it was ever registered?  Do you need an equal record keeping database to see where it was constructed?  What if it had someone’s named etched on it or a favorite movie quote?  Better yet, something scratched in the stock in German, Russian or Chinese?  None of these alone are indicative of ownership.  If you could look up a registration and track it to a person, it might have been stolen, misappropriated or sold and the registration not updated.  Not totally cool?  Absolutely.  Realistic as to what could have happened?  Definitely.  Malware isn’t even a sheet of paper thickness away from all that.


Malware written by one or more people?  Or course.  Are the owners to blame for how the malware is used?  Depends on your perspective.  When you see malware in your environment, who gets the attribution?   The malware designer and coder?  The person that sold or lost control of the malware (stolen from), or who gave it away (open source) for free or “educational” use?  The entity that deployed and used the malware?


What a tangled web we weave

Firearms, unlike malware, are tangible.   Being material, they have some natural limits, especially when it comes to handling.  I can envision a scenario where a firearm is used and handed off to multiple people.  It is still pretty limited.  As a material object, it is a bit tough to exist except singularly.  Malware doesn’t work that way.  I can have many, many, many exact duplicate copies all over the place.  I can use those many versions of the identical malware simultaneously across the globe.  It is a bit tough to point at one person and say, “Yeah, it’s you.  You are the one.”  Correlating a rifle that was used by a group of people at different points in time and locations, even if nearly identical — no problem, especially if I have the rifle and the location.  That type of arithmetic is done by law enforcement day in and day out like clockwork.  Perform that same function with malware?  Well….that’s a longer, more difficult and very different story.  Correlation within the context of the event?  Not so different than the above scenario with the rifle.  You have the malware and the location (your enterprise).  If you don’t have one of the two, then it’s almost impossible.  Perhaps you are evaluating a report of malware in another company, but you have acquired a copy of the malware in question.  Without the location of the event your correlation is sans numerous critical details, whose absence can seriously derail accuracy in analysis.


The same applies for when you go beyond your event.  You have malware in your enterprise and maybe others did too.  Research shows it; you can see it in the news.  Implication might hint at a connection, at least other than malware, but the ugly situation about bilocation of malware raises its ugly head.  Unlike the rifle, malware can be identical and in more than one location.  It can be owned and employed simultaneously, or otherwise, by different actors.  Some you might know and many others you have no concept even exist.  It’s a dark, tangled part of the forest full of dangers, of pitfalls and traps built to erode your time and analysis.  You need data points for correlation and confidence in that data as well.


Putting it all together — “M” stands for Malware

Here, is where the point of caution comes in.  The absolute initial step for the “M” in CHRIME is to outline the communication, composition, function, organization of the malware.  This is the Tier-I action that constitutes the first look at the malware.  Outline what you can, label that as confidently as possible and be ready to be wrong — at least, some of the time.  The potential for incorrectness is why malware is not a standalone check or information collection and correlation step.  A lot of intelligence can be derived from malware and related files, but it cannot stand alone.  It needs other data and correlation to be functional.  The next bit, if needed to reach the decision point, is deeper detail.  Go for accuracy and make sure what you have outlined is correct.  That means research, investigation and probably reverse engineering, or at least file interrogation.  The last step is to attribute.  Attribution is building a case of circumstantial and incomplete data.  It should be done with the thought that the best lawyers in existence are going to challenge every single piece of evidence, no matter how insignificant or compelling.


The tie-up activity, even if you skip deeper detail and attribution, is always to correlate the malware to the event.  You have malware.  The need to understand how it correlates and fits (or doesn’t) in the event is critical.  If the malware doesn’t belong to this event, then it belongs to a different one — an event you hopefully knew about and just missed the connection.  Otherwise, the string comes back to a python that can entangle and strangle you to death as you explain why it was missed and what damaged happened on your watch that you missed.  Someone’s head usually rolls in that situation.  That’s an ugly and unpleasant discussion to be avoided whenever possible.


That phish that almost got away

We’ve been using phishing as our example since Constellations.  I don’t want to get away from that.  Not all phishing has malware or leads to malware.  Social Engineering opens the doorway wide enough in most cases.  When it does or when it leads to malware, then it comes into frame.  Remember, we are always trying to get to a decision point with CHRIME.  A normal decision is whether to label an investigation or event an incident.  If you find something unusual in an investigation and it leads to malware, that could be an easy decision to make, especially if that’s corporate policy.  If you are tipped to malware, again, that’s an easy decision.  The follow on decisions to curtail permissions, shut down hardware, lock down access, and so on might be more difficult to determine.


In our phishing example, we had a phishing event that led to the discovery of a continuing campaign.  Malware isn’t part of the equation at the moment, as the point of the campaign has definitely been credential theft to gain access.  The ultimate goal is likely a future infiltration within unknown, but likely penultimate goal to do damage, steal data or gain access to information.  Those are speculative, but likely outcomes that can be war-gamed and understood.  If other hypotheses rise, they can be competed and other outcomes examined as needed.  Malware isn’t in play to date, but given the amount of previous information gleaned from analysis, threat hunting to determine its possible presence can now occur.  The question is constantly asked and the answer updated as new information becomes available.


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 6th discussion on the Malware component of CHRIME.  That leaves Execution for the next and last discussion piece on CHRIME.  If you missed the previous discussions, you can find the list of blog posts 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.