Most adversaries have a plan. Those plans vary greatly – in both complexity and rigor – from actor to actor, target to target. As we’ve discussed in prior posts, adversary plans are usually built from repeatable procedures – techniques and sub-techniques. The power of MITRE’s ATT&CK, CAPEC, or LMCO Kill Chain is that they help us track behaviors. Most of the time, I see organizations rush to address techniques through either detection & visibility or through protection. I think we all could use a dash of prevention – not just policy, but waaaay out front. We need to make even the selection of the plan difficult, and to reveal so little that the bad guys struggle to select the right plans. So let’s talk about making the recon phase hard for the adversary!

Importance of recon to the aggressor

I used aggressor so as to broaden the discussion a little. I love the story of the kill chain’s development, and in that case the attacker was (for most of us) the good guy. So first, it is story time!

When recon isn’t enough

During the first Gulf War, SCUD missiles were a feared threat, especially to allied bases and large population centers. While their accuracy was found to be lacking (thankfully!) they were mobile and had the potential to cause calamitous casualties. Allies expended a massive amount of resources to track these threats and hopefully eliminate them before launch. And this is where bureaucracy really kills the mood. Special forces units, at great personal risk, or reconnaissance aircraft, at huge cost, were very good at locating the targets. Their recon was fantastic.

So what was wrong? Well, it seems that there were a ton of steps between finding the threat and getting an air tasking order (ATO) planned, approved, and flying to the target. Remember, these were mobile targets! And the Iraqi army knew those were a hot item, so they were VERY eager to keep them moving. So the recon provided was nullified by the volatility of the data and the inefficiency of the cycle, or kill chain.

A few hours to act would be awful, but in truth those ATOs sometimes took over a week. In between seeing the SCUD and delivering a strike to eliminate it, there were a ton of layers. Multiple communications links to traverse. Several chains of command to route intel up and orders down. Prioritization and de-confliction. Almost always an inter-service or international exchange (or multiple). And then there is the planning, provisioning, scheduling, etc. It is so wonder any were hit! The allies and Iraqi army both contributed to making the recon phase hard.

Necessity begets the O.G. Kill Chain

Needless to say, the aggressor’s (US and their allies, in this case) realized after the 100 day operation that improvements needed to be made. So they built a Kill Chain model of it all and looked for the slop, inefficiency, and other issues. This process was just like a factory’s value chain processes in a Six Sigma sense. But in this case, they were not trying to reduce the production time, but the time-to-kill the target. This Kill Chain model was used to develop a lot of new weapons systems, streamline command and control processes, and modernize communications. In current day operations, those same cycles take minutes or hours, not days or weeks.

So what does this have to do with cyber threats?

I bring this up for a few reasons. First, it shows that the Cyber Kill Chain is simply a repurposing of the generic one developed by the US DoD with allies in the early 1990s. Second, it shares several stages, including the one we’re discussing today (Recon). Third, the time available between stages in an effective kill chain is directly impacted by the target’s paranoia AND their ability to change. This last part is – to me – the real fulcrum on which this entire stage rests. So we’ll talk shortly about how to make it pivot in the defender’s favor.

Why is do cyber targets need to make the recon phase hard?

Let’s switch back to adversaries in a cyber realm. As the first real stage of a campaign or attack, adversaries take this step to gather information they hope to use in refining their playbooks and adapting them to the future operations. It might sound boring, but these vital techniques are the homework that allow threat actors to effectively target their quarry, and they can’t stop just because the recon phase is hard. This group includes both passive and active techniques to gather that information.

A time for every purpose, including recon

Skilled adversaries in any domain (stealth aircraft & satellites, covert operators, submarines) may evade any detection while building amazingly complete pictures. Cyber makes this even more stealthy – much of what an adversary needs, they can gain without ever tipping off their targets. Because of the extremely low or non-existent detection risk, they can take their sweet time in capturing the essence of an environment. And the more accurate and detailed their homework is, the more precise they can make their successive stages. If the recon phase isn’t hard, this is a foregone conclusion.

The weightier factor

The inertia present in an IT environment is arguably the bigger factor. You can’t just tell DevOps to pull up camp and move every 5 days, change all characteristics, etc. Businesses rely on the very stability and predictability that makes them an immobile target – so they must withstand attacks knowing full well the adversary knows where they are and a lot about them. Defensively, it can take them years to alter defensive posture, implement new solutions, or train their staff. So the adversary knows that there is a great chance that their intel is relevant and accurate, even if it takes them a few weeks or months to build the picture.

I do think it is worth noting that while the LMCO Kill Chain and ATT&CK are both shown as serial, left-to-right timelines, that is not how it works in the real world. Threat actors (or Red Teams) are going to take every possible opportunity to refresh their picture of the target with things learned at each stage.

Low hanging fruit

So what are the adversaries after? IT targets present a few dimensions that competent adversaries will take a look at, using the techniques as shown in MITRE’s ATT&CK Reconnaissance Tactic (TA0043).

The Recon Phase is a doozy – but we don’t have to let it happen!
  • Traits:
    • Adversaries can use free and open tools, third party services, and more to catalogue and map hosts and infrastructure by their:
      • IP addresses
      • Domain names
      • Open ports
      • Exposed APIs
      • Versions, vendors and more.
    • Search engines like Shodan, Google dorks, Cencys, BuiltWith, or even the Wayback Machine can be invaluable here!
    • Slightly more active, DNS recon tools like Dig or scanners like nmap or masscan can be used from burnable infrastructure to accelerate.
  • Value:
    • Along with the traits above, deductive reasoning and some knowledge of the applications present will likely help rate each potential target’s value. That value might come from:
      • Information
      • Vantage point or suitability from which to pivot
      • Potential impact to victims when impaired
    • Domain knowledge is pretty important here, but surprising information can be gleaned from well-meaning posts via blogs, job postings, technical support portals, and more.
  • Defenses:
    • Some recon can – without ever tipping off the victim – offer insights into what defenses are in place. Things like:
      • Which vendors are in use for a security function
      • Error messages may reveal too much detail that tips off an application, database, or security solution in place
      • Security staff may post questions about their implementation, or list it as an accomplishment on social media.

Special Note about Social Engineering

Phishing, vishing, and smishing are fairly low-risk for the adversary. Each can be used to help flesh out any of the above. We see these social engineering augmentations to Recon happen after some initial intel gathering so that it looks more realistic.

There are probably a ton more dimensions to think about, but you get the idea. Recon really makes the target selection and best approach for attack obvious to a reasonably skilled adversary. And if we don’t make the recon phase hard, they’ll be hard to beat.

Our mistakes & becoming more mysterious

There are some things that are avoidable, but given all that a “reconning” adversary might be looking for, what can we change to make the recon phase harder?

Limit social media and open support use

As you probably surmised while reading about the dimensions, our first issue is that we disclose way too much via open systems. I have seen folks post configuration snippets and details in Stack Overflow, vendor support forums, or even Reddit. Even worse, they usually value their social media presence way more than their corporate security, so a little bit of OSINT makes linking the username to a real person and employer simple. Some employees may also use public tools like GitHub, GitLab, or Bitbucket. The number of breaches that are now occurring due to inadvertent disclosure of secrets, sensitive code, infrastructure details, and more via these tools is staggering.

Enforce stronger policies against this behavior – come up with suitable support processes that allow secure sharing of configurations with ONLY trusted support staff, not millions of interested bystanders too. Limit or come up with impressive but more elusive snippets that employees can use to flesh out their LinkedIn profile. Host or strongly police the use of repositories online, and monitor them with a good CSPM solution. Modern DLP and CASB approaches can also help somewhat with the posting and sharing of information – some will even help police what gets posted to AI LLMs.

Lastly, it should go without saying – employees should never reuse corporate credentials on other systems. Social media, personal accounts, and more are much more likely to be compromised, and any perceived links to the employer will be investigated quickly.

Don’t let job descriptions sink you

Human Resources has a vital role in finding talented people, and security staff is a pretty critical area for most. As an industry, however, there is a tendency to over-load a requisition. We see entry-level roles requiring 10 years of experience, or a plethora of certs that together indicate a unicorn is needed. Somehow those same requisitions explicitly list the solutions in use – either the applications critical to the business or the security capabilities that protect them. An attentive adversary will note these details and assume that those solutions are either in place or planned.

We can blame HR for this over-sharing, but it is essential that we help them write the requisitions to both avoid being an over-qualification punchline and giving up state secrets for our organization. There are smart ways to bring in viable candidates – generalize the solution terms, and let the resume proactively self-identify the appropriate vendor skill set, if need be. Focus on concepts, or industry terms, not on specifics. And invest in helping HR and the hiring team collaborate to jointly screen and evaluate candidates.

Make systems more obtuse

This works on a lot of levels. Fundamentally, adversaries should be unable to scan past your front door. Which we often see this prevented with restrictive ICMP policies, don’t forget that there are a lot of other services and OSI layers that can be probed!

Detailed error messages when encountering issues in a web application are super helpful in revealing what went wrong. To everyone. The truth is, the issues that these overly detailed messages assist with should be solved long before an application makes it into production. Leaving them in place past that push can help a nosy adversary very quickly zero in on the solution, its version, and even features that might be in place. And these data points all help refine an adversary’s game plan for tackling these systems.

Working with NetOps and SysOps, harden hosts and infrastructure to eliminate visibility. This falls in the simple hygiene category, but it is amazing how many mission critical systems show up on Shodan or can be reached with a simple banner scrape. This isn’t just a firewall or perimeter task – hosts should only expose ports needed and even then, only to trusted systems.

Working closely with your DevOps team, try to find ways to generalize those messages as part of the QA stage – run tests to ensure that no one can glean what version of SQL is running, or which WAF or proxy might be interfering. Likewise, there are many ways to configure defensive solutions. Limit what they reveal when scans happen, or traffic is rejected. Keep the bad guys guessing!

Taking some new steps

All of the above focuses on saying less and making the recon phase hard. That complicates the effort an adversary must do to build a useful dossier. Recent developments in deception technology and detection methods can also help a lot.

An extension of the honeypot or honeynet, a deception technology like a tarpit may be useful. These solutions slow or stop adversaries by presenting simulated target spaces that look enticing but send the bad guys on a cyber version of a snipe hunt. These tools not only burn a ton of time, but in the right hands can really help characterize the adversary’s behavior and allow for counter-recon of sorts. In the process of chasing these phantom targets and getting bogged down, the adversary may reveal their own infrastructure, inadvertently expose their techniques and tools, and make it easy for the intended victim to block those from having an impact and alert others to the traits. I really like the Active Countermeasures ADHD for playing with a variety of Honeynet and Deception tools.

the BHIS/Active Countermeasures crew has made a pretty awesome open-source tool for playing with Annoyance, Attribution, and Attack tools in defense šŸ™‚

Even more simply, canary accounts or tokens are useful detection tricks work a look. By peppering seemingly legitimate but heavily logged accounts throughout an IAM/IdP solution, it can become a tripwire for inappropriate use of accounts. Likewise, files and tokens might be implanted in places that an adversary may mistake for legitimate, and when stolen, activated, or re-located maliciously, could easily trip an alarm to the defenders and trigger a defensive countermeasure.

Conclusion

Reconnaissance is a vital step for any aggressor, be they good (allies, Red Teams) or bad (threat actors). The more we can do to make recon phase hard and their life uncomfortable or difficult, the better our chances of withstanding their attacks and exposing their techniques. While they can typically take their time, any chance we can take to make their efforts fruitless – or even better – trigger some early warnings, the better. Hopefully this post is helpful in understanding how recon is important and how to make the recon phase harder on the bad guys!