Cyberweekly #187 - Advanced attackers aren't always advanced

Published on Sunday, March 06, 2022

Cyber Realism in a Time of War

https://www.lawfareblog.com/cyber-realism-time-war

There has been no shortage of predictions over the past two decades about the importance of the digital domain in conflict since John Arquilla and David Ronfeldt warned that “cyberwar is coming” in a Rand Corporation paper back in 1993. As recently as November 2021, British Prime Minister Boris Johnson remarked in a testy exchange with Tobias Ellwood, chairman of the committee of the House of Commons that oversees defense, that “the old concept of fighting big tank battles on the European land mass are over … there are other big things that we should be investing in … [like] cyber—this is how warfare of the future is going to be.”

Ellwood, a strong critic of the British government’s decision to cut Army personnel in favor of investment in cyber capabilities, replied, “You can’t hold ground in cyber.” And on military tactics, if nothing else, Russian President Vladimir Putin seems to have agreed with him. Despite being one of the world’s foremost offensive cyber powers, the Russian invasion of Ukraine has, thus far, been utterly conventional in its brutality as the horrific pictures from Kyiv, Kharikiv and other cities show on an hourly basis. And Ukraine’s heroic resistance is similarly centered on the traditional understanding of war.

Even those of us long skeptical about the mischaracterization of cyber operations and cyber risk as catastrophic weapons of destruction, rather than a still serious but quite different threat of chronic disruption and destabilization, have been surprised by just how little cyber operations have featured in the early part of the invasion.

[...]

Predicting how this aspect of the conflict turns out is extremely difficult. But preparing for it starts with grappling with what the cyber capabilities are, how they work and what impact they have. And not every American policymaker seems to have Alperovitch’s expert understanding of the complexities. The day after the invasion began, NBC News reported that President Biden had been presented with a range of options for a cyber response against Moscow. Speculating that tampering with railroad switches could be part of the plan, one anonymous U.S. government source mused that “you could do everything from slow the trains down to have them fall off the track.”

That one sentence encapsulated the many misunderstandings of cyber capabilities, which perhaps explains why the White House dismissed the whole NBC story in unusually strident terms. There is a hierarchy of cyber operations from the extremely basic to the most sophisticated. Difficulty rises in correlation. Anyone can have a go at taking down a Russian government website. Taking a medium-size—or, too often, even a large—company offline is well within the capabilities of low-sophistication criminals. Doing something like slowing the trains down by sabotaging the signaling is usually much harder. The sorts of capabilities to do that belong to a handful of nation-states. Forcing trains off tracks takes you into the realm of Hollywood cyber fantasy: Cyber operations are computer code, and any railway system worthy of the name does not have a computer that can be reprogrammed to drive trains off the tracks.

Excellent analysis by Ciaran Martin here. Cyber and cyber warfare is misunderstood by policy makers, think tank analysts and technologists alike. Very few people have the mix of foreign policy experience, technological understanding and military theories to actually make determinations of what’s possible, likely or merely fiction in these times.

Srsly Risky Biz: Thursday March 3

https://srslyriskybiz.substack.com/p/srsly-risky-biz-thursday-march-3

There is no evidence that cyber operations have been used effectively in support of conventional military action in Russia's invasion of Ukraine, but the resulting chaos in the cybers is still making life interesting.

[...]

These kinds of nuisance attacks are ongoing and there are a lot of them , but we haven't seen the broadly destructive attacks that Russia has used against Ukraine in the past such as NotPetya in 2017 or the electricity network disruptions in 2015 and 2016 .

In this case, we're yet to see any evidence that a cyber operation has provided Russia with the kind of decisive military advantage that cyber enthusiasts fantasise about. Of course, it could be that Russian forces simply aren't capable of taking advantage of a disruptive cyber operation. Australian Major General (retired) Mick Ryan described Russian military leadership as " professionally corrupt and incompetent " and the progress of Russian forces near Kyiv as " slow and plodding ".

Another possibility is that — at least for some things like the telecommunications networks — more drastic disruption hasn't occurred because Russian forces need them. Russian communications equipment is unbelievably bad and troops are using both unencrypted radios and smartphones for communications. This is allowing a collective amateur SIGINT effort and also possibly providing the opportunity for the Ukrainian government to monitor phones. NATO country SIGINT agencies must be having a field day.

Risky Business, which is also an excellent podcast, does a really good summary of the current Ukraine situation here.

Most importantly, it’s very difficult to ascertain the why of any part of the situation at the moment. We can see some of what is happening, although I’d wager we see less than we think in “cyberspace”, but we may struggle to make sense of it, mostly because of the “fog of war”, but also because individuals are acting independently on their own view of information. So actions may make sense to one actor, that don’t make sense to their own sides generals, or make sense to observers.

But what is clear is that despite years, even decades of dire warnings about Cyberwar, we are not seeing the sky falling just yet.

GitHub - Res260/conti_202202_leak_procedures

https://github.com/Res260/conti_202202_leak_procedures

This repository contains procedures found in the Feb 2022 conti leaks. They were taken from the "manual_teams_c" rocketchat channel in the leak and posted on may 10th, 2021 in the channel.

This is quite the set of procedures from the Conti manual. It tells new affiliates how to hack into peoples systems and use the tools provided.

It’s a good reminder that although many cyber threat intelligence firms go on about advanced persistent threats as if they are gifted individual hackers who can bend the matrix to their will like an incarnation of Neo, they are mostly just script kiddies, running the commands they’ve been told to run.

If you can disrupt the early commands that they run, or deceive them with tools like canaries and deception engineering, then they likely don’t have the skills to pursue it further.

Invest in those “basic defences” that some people will tell you won’t stop advanced attackers, and chances are, you’ll still stop “middling advanced attackers”

Conti Ransomware Group Diaries, Part I: Evasion – Krebs on Security

https://krebsonsecurity.com/2022/03/conti-ransomware-group-diaries-part-i-evasion/

A Ukrainian security researcher this week leaked several years of internal chat logs and other sensitive data tied to Conti , an aggressive and ruthless Russian cybercrime group that focuses on deploying its ransomware to companies with more than $100 million in annual revenue. The chat logs offer a fascinating glimpse into the challenges of running a sprawling criminal enterprise with more than 100 salaried employees. The records also provide insight into how Conti has dealt with its own internal breaches and attacks from private security firms and foreign governments.

This saga is going to run and run. There’s no better insight into the operation of a modern ransomware organisation than this, and Conti has been subject to leaks before, including their training manual for affiliates that covers the best ways to attack an organisation.

“Almost done” doesn’t count – niksilver.com

https://niksilver.com/2022/02/26/focus-on-done/

Quite a while ago I changed my approach slightly to facilitating a team’s daily stand-up meeting. Instead of going through the items on the board from left to right, I asked about them from right to left. Things towards the right are closer to done, so the idea is to focus on getting the “almost done” work actually done, and so delivery is more successful.

Of course, this lesson does not originate from agile software development, it’s just a general lesson about working life—“almost done” doesn’t count, only “really done” is useful to anyone. But I find it’s harder to apply that rule in everyday working life, perhaps because everyday working life isn’t as well-structured as a team that has tickets on a board and daily meetings.

Like everyone else I know, I’ve often got too much to do in any one day. And there are so many tasks on my task list that it’s too easy to switch back and forth between them. Perhaps this is to avoid the sense of being overwhelmed. Move this task a bit, move that task a bit, move a third task forward… everything makes progress, but nothing gets completed.

I find I really have to focus to get something actually done. But I’ve also found that when it does reach that “done” state it actually makes a noticeable difference. That’s not just because of the thing itself, it’s because I’m just one person contributing to a much bigger effort. The thing I’ve done enables much bigger things to happen. This shouldn’t be too surprising, because we’re all part of a bigger team and a bigger organisation, even if we may sometimes feel a bit isolated.

This is a really useful point to remind ourselves on.

It feels like if we’re juggling things, that we’re making progress if we move everything on just a little bit. But it’s far more efficient overall to get rid of one of the balls you are juggling.

Prioritising the work to get 1 thing finished over the work needed to get everything advanced just a bit feels difficult. but almost certainly pays bigger dividends in the long run.

Six things I've learned from 15 years at ZDNet

https://www.linkedin.com/pulse/six-things-ive-learned-from-15-years-zdnet-larry-dignan

Technology and careers are about the middle of the Venn diagram. When I started the ZDNet adventure, cloud computing wasn't even a thing . Salesforce was just a baby with growing pains. Netbooks were a thing for a bit and then weren't and now you have Chromebooks. I've seen more CES products never happen than I can count. The next big thing usually isn't, but what's clear is that intersections matter. Technologies may have been early but often pave the way for something else as an enabler. Quantum computing won't be consumed without cloud computing. Edge computing evolved due to the mix of cloud and data centers and 5G. Converged infrastructure is all about the intersection of technologies. Thanks to computing gains, AI and machine learning has become operationalized. IT used to be separated from the business. Now IT is the business.

Careers are often about the intersections too. The tech leaders of today also are well versed in business. Teams building AI need liberal art types. Journalists need to know the business and their ROI. Maybe someone who knows healthcare delivery from the front lines should run hospital operations over consultants and MBAs. Pick two themes, find the middle ground between two sides that don't understand each other and you have a career.

Great advice here all round, but this here about intersections is really valuable.

The best SOC I’ve ever seen doesn’t just hire “Security Analysts”, it has a small team with a mix of data scientists and statisticians, sysadmins and devops and security specialists.

The best teams are the ones who bring in new and novel thinkers who have been exposed to outside ideas. The fusion of ideas and people, from the sciences to the humanities, from well educated to self educated, from rich and from poor backgrounds gives us as a team a far better understanding of the world, and what works and doesn’t work.

What’s the worst leadership advice you’ve heard?

https://twitter.com/jmwind/status/1493569303030816770

Q. What’s the worst leadership advice you’ve heard?

A. By far the worst is “Hire great people and get out of their way”.

This resonated with me. I’ve always been uncomfortable with the ego-driven “Developer as kingmaker” assumption that the best way to deliver for an engineering organisation is to just get out of the developers way.

In practice, you need to hire brilliant developers, who care about the organisations goals, you need to give them the context and the vision of where the organisation is going, and what problems you can see coming down the line, and then and only then, can you get out of their way.

Alignment and Autonomy aren’t in opposition to one another, but the dream of complete autonomy simply isn’t rational for most engineers in a bigger company.

Meaningless Measurement – johnJsills

https://johnjsills.com/2022/02/24/meaningless-measurement/

We’re living in an epidemic of feedback requests.

It’s become impossible for a customer to call, make a purchase, or visit a website without an automated email appearing to ask for their opinion.

Of course, this comes from a good place. A place of organisations wanting to be closer to their customers, to understand the experience they’re providing.

Except, in most cases, it doesn’t do that. 

Instead, it creates a mountain of data focussed on averages not actuals, giving the impression that the experience is broadly fine whilst hiding the extreme experiences that have a deep impact on customers. An average call waiting time of five minutes is less interesting than knowing 5% of customers waited for half an hour.

Secondly, this slew of surveys gives the impression of being close to customers, but actually shields senior leaders from reality. People are reduced to numbers and pictures on a PowerPoint, the emotion in their customers’ experience stripped away and replaced with binary opinions on what matters to the business. Any unappealing results are often put down to the wrong sample size or a mistaken methodology. 

Lovely writeup of the tyranny of customer service surveys, the load they put on users and the often utterly valueless data they give to the organisation that does them

GitHub - defenseunicorns/zarf: K8s Airgap Buddy

https://github.com/defenseunicorns/zarf

Zarf massively simplifies the setup & administration of kubernetes clusters "across the air gap ".

It provides a static go binary CLI that can pull, package, and install all the things your clusters need to run. It caches downloads (for speed), hashes packages (for security), and can even install the kubernetes cluster itself if you want it to.

Zarf runs on a bunch of operating systems and aims to support configurations ranging from "I want to run one, simple app" to "I need to support & dependency control a bunch of internet-disconnected clusters".

Internet connected is considered the be-all and end-all of systems today, and Zero Trust models talk about “use the internet”, when in fact we sometimes mean “internet standards and technologies”.

Airgapped systems are really hard to work with, and people managing them tend to break the model in lots of ways because it’s simply not practical without huge amounts of effort. But one of the key problems is that if you have an airgapped system, you still want to use internet era technologies and systems, and that means deploying and patching systems.

This is a really interesting project, backed by the US DoD, which is designed to automate a lot of the work to package up systems so they can be auditably and sensibly transfered across to an airgapped system.

There’s lots of reasons that a corporation might want to do this, lots of places where knowing that only your staff on your network can access something, and yet you still want to apply existing good practice like GitOps and K8s deployments.

Brett Callow on Twitter: "Lapsus$ claim responsibility for the hack on Nvidia - and also claim that Nvidia successfully hacked back. https://t.co/F8ocpB6Qev" / Twitter

https://twitter.com/brettcallow/status/1497627779755438083

Absolutely fascinating claim here that NVidia hacked back.

In this case, the attackers deliberately enrolled their attacking system into NVidia’s MDM solution, so NVidia used that MDM solution to encrypt it. It likely slowed down the attackers, but they almost certainly had moved the data off of the machine (based on reports at least)