Extra quote of the day

"All advantage goes to the offense in cyber. It just does. On the defensive side, you have to say 'I must defend all 100,000 machines, all 50,000 employees.' The offensive side thinks, 'I only need to break into one and I'm on the inside.'"

--Kevin Mandia

This is one of the key reason for Red Teaming. Act, don't react.

Quote of the day

"What is the difference between describing 'how' and explaining 'why'? To describe 'how' means to reconstruct the series of specific events that led from one point to another. To explain 'why' means to find causal connections that account for the occurrence of this particular series of events to the exclusion of all others."

--Yuval Harari, Sapiens: A Brief History of Humankind

/

Army’s Red Team Exposes Technology Vulnerabilities

From that point on, anything deployed to small forward operating outposts of 300 people or less gets a Red Team going over from “the construct of the operational perspective, technology perspective, and how we could integrate it in such a way not to create inherent vulnerabilities. It’s been very effective.”

/

Quote of the day

"A human being should be able to change a diaper, plan an invasion, butcher a hog, con a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

—Robert Heinlein

CP Journal Blog

Patrick Van Horne, the write of Left og Bang has a couple of very interesting posts touching the topic of observation on his website. Worth checking.

Identifying people who are familiar and unfamiliar with their surroundings

How I Break Down A Video

Sherlock Holmes, Red Teamer

A really good point and explanation at the Red Team Journal.

Holmes explains to Dr. Watson the ability to “reason backwards”:

In solving a problem of this sort, the grand thing is to be able to reason backwards. That is a very useful accomplishment, and a very easy one, but people do not practise it much. In the every-day affairs of life it is more useful to reason forwards, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically…. Let me see if I can make it clearer. Most people, if you describe a train of events to them, will tell you what the result would be. They can put those events together in their minds, and argue from them that something will come to pass. There are few people, however, who, if you told them a result, would be able to evolve from their own inner consciousness what the steps were which led up to that result. This power is what I mean when I talk of reasoning backwards, or analytically.

As red teamers, we often posit what the adversary wants (“a result”) and then “evolve from [our] own inner consciousness what the steps were which led up to that result.” Whether all red teamers do, in fact, have an “inner consciousness” is an open question, but at least when it comes of reasoning backwards, nearly all of us share this ability with the great Mr. Holmes.

/

Think Like a Green Beret: Problem Solving | Loadout Room

This article has a good example of the right mindset. I'm finding more and more that having the right focus, the right mindset will take you further and help you in a small team environment.

Many times, military problems must be solved with the application of force. Green Berets are not afraid to get their hands dirty, but they understand the power of working with and through others.

/

osascript: for local phishing

A little digital foo for the saturday: osascipt.

FuzzyNop wrote:

Lately I've been finding myself on victim's laptops and they have all been OSX. I found that instead of key-logging I could simply prompt the end user for whatever password I needed using applescript.

The way we do this is with osascript, Apples built in executor for applescript and other OSA (Open Scripting Architecture) languages. Applescript provides a convenient way to interact with GUI elements within OSX so this little trick is likely only scratching the surface of what is possible.

So straight to it, the command i'm using to do this looks like this:

osascript -e 'tell app "System Preferences" to activate' -e 'tell app "System Preferences" to activate' -e 'tell app "System Preferences" to display dialog "Software Update requires that you type your password to apply changes." & return & return default answer "" with icon 1 with hidden answer with title "Software Update"'

Follow the link to read all the article.

/

Red Teaming the Plans

One of the most important things you can do when you have a plan is to make sure it will survive Mr. Murphy, to the best of your effort.
We've talked about this many times in the blog, but here's a small brain dump of what Red Teaming the plans would look like. your mileage may vary, thought, depending on the plan.

Once you have a plan in place, bring your team and identify the risks, threats and vulnerabilities.

  • Risk: is the the likelihood of being targeted by a given attack.
  • Threat: is what could happen.
  • Vulnerability: is the weakness that an adversary will exploit to make the attack successful.

Translated to the plan: what could break the plan, how and by what.

There are three steps to follow now.

  1. Identify the key aspects of the plan.
  2. Identify threats most likely to impact those parts of the plan.
  3. Determine the vulnerabilities that might make those threats real.

Start by listing the most important parts of the plan, those parts that would cause it to fail if they don't happen. Rank them by criticality:

  • Critical: the plan will fail.
  • Essential: the plan might fail but you can still run a contingency.
  • Non-Essential: good to have, but it if doesn't happen the plan will still succeed.

Write them on a whiteboard, make a table listing each one by critical ranking.

Next, ID the threats. Ask questions like: What can happen? When? What is most likely to happen? How? Write the questions and the answers next to each part identified. Give a probability rank to those threats:

  • High: this will most likely happen.
  • Medium: there is a chance of this happening, but we have mitigating controls.
  • Low: it will rarely happen.

You should have in front of you now, a table with the most important parts of the plan, how critical they are and the threats to those parts marked by probability. You can begin to see already the parts that are most likely to fail and how important they are.

The next step is thinking about the vulnerabilities. Which of the threats identified above have the greatest likelihood of disrupting the plan? How? What is the thing that can break that would cause that threat to become real? Things like equipment failure due to batteries, weather causing traffic and delaying execution, etc.

Add them to the table you are drawing.
You should have, at this point, a clear picture of the things that could go wrong with the plan.

Now focus on the critical parts and high probability threats. Discard for now anything else. List the possible solutions for those and add them to the plan.

When you are done, bring the 10th man. Bring an external party and show him/her the entire plan. Check what he/she can see. Now you are ready.

Remember Rule 29: If you’re happy with your security, so are the bad guys.

Oh, and don't forget to play with the CARVER Matrix.