Monthly Archives: July 2020

An early-warning system for cyber-rangers (aka – Adaptive Anomaly Control).

Most probably, if you’re normally office-based, your office right now is still rather – or completely – empty, just like ours. At our HQ the only folks you’ll see are the occasional security guards, and the only noise you’ll hear is the hum of the cooling systems of our heavily-loaded servers given that everyone’s hooked up and working from home.

You’d never imagine that, unseen, our technologies, experts and products are working 24/7 protecting the cyberworld. But they are. But the bad guys are up to new nasty tricks at the same time. Just as well, then, that we have an early-warning system in our cyber-protection collection of tools. But I’ll get to that in a bit…

The role of an IT security guy or girl in some ways resembles that of a forest ranger: to catch the poachers (malware) and neutralize the threat they pose for the forest’s dwellers, first of all you need to find them. Of course, you could simply wait until a poacher’s rifle goes off and run toward where the sound came from, but that doesn’t exclude the possibility that you’ll be too late and that the only thing you’d be able to do is clear up the mess.

You could go full-paranoiac: placing sensors and video cameras all over the forest, but then you might find yourself reacting to any and every rustle that’s picked up (and soon losing sleep, then your mind). But when you realize that poachers have learned to hide really well – in fact, to not leave any trace at all of their presence – it then becomes clear that the most important aspect of security is the ability to separate suspicious events from regular, harmless ones.

Increasingly, today’s cyber-poachers are camouflaging themselves with the help of perfectly legitimate tools and operations.

A few examples: opening a document in Microsoft Office, a system administrator being granted remote access, the launch of a script in PowerShell, and the activation of a data encryption mechanism. Then there’s the new wave of so-called fileless malware, leaving literally zero traces on a hard drive, which seriously limits the effectiveness of traditional approaches to protection.

Examples: (i) the Platinum threat actor used fileless technologies to penetrate computers of diplomatic organizations; and (ii) office documents with malicious payload were used for infections via phishing in the operations of the DarkUniverse APT; and there are plenty more. One more example: the fileless ransomware-encryptor ‘Mailto’ (aka Netwalker), which uses a PowerShell script for loading malicious code directly into the memory of trusted system processes.

Now, if traditional protection isn’t up to the task, it’s possible to try and forbid to users a whole range of operations, and to introduce tough policies on access and usage of software. However, given this, both the users and the bad guys will eventually probably find ways round the prohibitions (just like the prohibition of alcohol was always gotten around too:).

Much better would be to find a solution that can detect anomalies in standard processes and for the system administrator to be informed about them. But what is crucial is for such a solution to be able to learn how to automatically determine accurately the degree of ‘suspiciousness’ of processes in all their great variety, so as not to torment the system administrator with constant cries of ‘wolf!’

Well – you’ve guessed it! – we have such a solution: Adaptive Anomaly Control, a service built upon three main components – rules, statistics and exceptions.

Read on…

Cyber-yesteryear, pt. 8: 1998-2000 (three firsts: restructuring, overseas office, partner conference).

The first few years after the founding of the company were the toughest of all because we really had to put the hours in, aka, bust our asses. It was like we were compressing a spring for it only later to be released to take the company up high and far beyond the horizon and in the right direction of pipe dreams (be careful what you have pipe dreams of:). After the formal registration of KL in 1997, with very little we did an awful lot. We had no money and hardly any resources, but the cybersecurity conveyor waits for no one: new technologies were needed, and the market demanded new products. So we toiled and slogged, working most weekends, and with hardly ever a vacation. So what were we working on? Here’s an example…

June 1998: the global Chernobyl (CIH) virus epidemic. All the other AV companies either didn’t notice it or didn’t bother with it, or were on vacation; we were almost the only one with a product that not only caught, but also cured systems infected with this pathogen. The www (i.e., already not just Runet:) was dotted with links to our site. That’s how we were rewarded for our super-speedy reactions to new threats – that and our ability to launch quick updates with procedures for treatment of specific threats. While this specific virus-threat incredibly craftily installed itself into Windows memory, hooked file-access calls, and infected executable files – all of which required a custom-designed dissection process that would have been impossible to deliver without flexible functionality of updates.

So – tough: yes; but we were getting results and growing. And then, two months later, we received a helping hand (of fate?!) of the most unexpected kind…

August 1998: the Russian financial crisis, featuring devaluation of the ruble, plus Russia defaulting on its debt. It was bad for most Russians on the whole, but we were reeeaaal lucky: all our foreign partners paid us in advance in foreign currency. We were an exporter. Our operating/working currency – a heavily devalued ruble; our income – dollars, pounds sterling, yen, etc. We were in the money!

But we didn’t rest on our ‘lucky’ laurels amid the financial crisis. We used the period also to take on new, professional – expensive! – managers. Soon we had commercial, technical and finance directors. And a little later we started to take on mid-level managers too. This was our first ever ‘restructuring‘ – when the ‘team’ became a ‘company’; when friendly, organic relations were replaced by a more formal organizational structure, subordination and accountability. The restructuring could have been painful; thankfully it wasn’t: we just got on with it without too much nostalgia for the old family-like times.

// For all about this kind of reorganization-restructuring-‘reengineering’ – I highly recommend the book Reengineering the Corporation by Michael Hammer and James Champy. It’s a real good one. Other useful books – here.

In 1999 we opened our first foreign office – in Cambridge in the UK. But, like, what with the British market being perhaps one of the toughest to crack for foreigners, why there? Actually, it was kinda just by chance (I’ll tell you how below). Still, we had to start somewhere, and anyway, our first experiences – including many mistakes and lessons learned – in the UK helped in making development of the business in other countries run a lot smoother…

Our first ever press tour took place in London, as we were in the British capital anyway for an IT security conference (InfoSecurity Europe). On that press tour we proudly announced our intention of opening an office in the UK. But the journalists would simply ask why, given that there were already Sophos, Symantec, McAfee and so on already comfortably established in the country. So we switched to geek mode: we told them all about how our company was a truly innovative one, and all about our unique technologies and products and how – because of them – we’re better than all the competition they’d just mentioned. All this was noted with much surprised interest (and another bonus: ever since then really silly questions have never been asked of us!). Meanwhile, at InfoSecurity Europe I gave my first ever speech to an English-speaking audience made up of… two journalists, who turned out to be from our friends at Virus Bulletin who already knew plenty about us! Still, that was the first – and last – time any of our presentations weren’t full-house (btw: details – here).

As regards our first ever partner conference, here’s how that came about..

Some time in the winter of 1998-1999 we were invited to the partner conference of our OEM partner F-Secure (Data Fellows). And that’s how we learned about the whole partner-conference format and what a great idea it is: to gather everyone together, share all the latest information about technologies and products, to hear out partners’ concerns and problems, and to discuss new ideas. Not ones to hang about – within a year (in 1999) we put on our own partner conference, inviting ~15 partners from Europe, the U.S. and Mexico to Moscow. Here we all are, on Revolution Square next to Red Square and the Kremlin:

Read on…

Playing hide and seek catch – with fileless malware.

Malicious code… – it gets everywhere…

It’s a bit like a gas, which will always fill the space it finds itself in – only different: it will always get through ‘holes’ (vulnerabilities) in a computer system. So our job (rather – one of them) is to find such holes and bung them up. Our goal is to do this proactively; that is, before malware has discovered them yet. And if it does find holes – we’re waiting, ready to zap it.

In fact it’s proactive protection and the ability to foresee the actions of attackers and create a barrier in advance that distinguishes genuinely excellent, hi-tech cybersecurity from marketing BS.

Here today I want to tell you about another way our proactive protection secures against yet another, particularly crafty kind of malware. Yes, I want to tell you about something called fileless (aka – bodiless) malicious code – a dangerous breed of ghost-malware that’s learned to use architectural drawbacks in Windows to infect computers. And also about our patented technology that fights this particular cyber-disease. And I’ll do so just as you like it: complex things explained simply, in the light, gripping manner of a cyber-thriller with elements of suspense ).

First off, what does fileless mean?

Well, fileless code, once it’s gotten inside a computer system, doesn’t create copies of itself in the form of files on disk – thereby avoiding detection by traditional methods, for example with an antivirus monitor.

So, how does such ‘ghost malware’ exist inside a system? Actually, it resides in the memory of trusted processes! Oh yes. Oh eek.

In Windows (actually, not only Windows), there has always existed the ability to execute dynamic code, which, in particular, is used for just-in-time compilation; that is, turning program code into machine code not straight away, but as and when it may be needed. This approach increases the execution speed for some applications. And to support this functionality Windows allows applications to place code into the process memory (or even into other trusted process memory) and execute it.

Hardly a great idea from the security standpoint, but what can you do? It’s how millions of applications written in Java, .NET, PHP, Python and other languages and for other platforms have been working for decades.

Predictably, the cyberbaddies took advantage of the ability to use dynamic code, inventing various methods to abuse it. And one of the most convenient and therefore widespread methods they use is something called reflective PE injection. A what?! Let me explain (it is, actually, rather interesting, so do please bear with me:)…

Launching an application by clicking on its icon – fairly simple and straightforward, right? It does look simple, but actually, under the hood, there’s all sorts goes on: a system loader is called up, which takes the respective file from disk, loads it into memory and executes it. And this standard process is controlled by antivirus monitors, which check the application’s security on the fly.

Now, when there’s a ‘reflection’, code is loaded bypassing the system loader (and thus also bypassing the antivirus monitor). The code is placed directly into the memory of a trusted process, creating a ‘reflection’ of the original executable module. Such reflection can be executed as a real module loaded by a standard method, but it isn’t registered in the list of modules and, as mentioned above, it doesn’t have a file on disk.

What’s more, unlike other techniques for injecting code (for example, via shellcode), a reflection injection allows to create functionally advanced code in high-level programming languages and standard development frameworks with hardly any limitations. So what you get is: (i) no files, (ii) concealment behind trusted process, (iii) invisibility to traditional protective technologies, and (iv) a free hand to cause some havoc.

So naturally, reflected injections were a mega-hit with developers of malicious code: At first they appeared in exploit packs, then cyber-spies got in on the game (for example, Lazarus and Turla), then advanced cybercriminals (as it’s a useful and legitimate way of executing complex code!), then petty cybercriminals.

Now, on the other side of the barricades, finding such a fileless infection is no walk in the cyber-park. So it’s no wonder really that most cybersecurity brands aren’t too hot at it. Some can hardly do it at all.

Read on…

Enter your email address to subscribe to this blog
(Required)

Easing back to (a new) normal.

We’d just started getting used to – even comfortable with – working from home every day and to ‘social’ distancing (wouldn’t ‘physical’ distancing have been a better term?:). Our partner conferences and other events had only just got back up to pre-lockdown scale in terms of the number of folks taking part – albeit online. I’d just gotten used to 10/15/20 kilometers of running of a morning before breakfast. In short, everything was going in one direction. But then the other day, out of the blue, suddenly things seemed to slam into reverse when I was asked, via the good K folks in our PR department, to do an interview – ‘on camera, in the office – tomorrow please!’. Well, well. All righty!…

Indeed, it looks like were heading back, slowly, to ~normality, despite the masks and sanitizer, after months without normal daily social interaction in person. Part of me thinks: ‘Good’ – let’s get back to work‘ (a fave phrase of mine). Another part of me recalls: ‘But, we have been working – as normal – throughout the whole of lockdown!’. Still, I do miss the office – seeing people, being among people, talking to people in person, as I’m sure many do, despite some of the upsides to working from home which surprisingly became apparent.

Anyway, the other day, I gave my first physically face-to-face interview in over three months. It was about one of our (cloud-related) business partnerships. Hmm – actually, it wasn’t quite ‘face-to-face’; it was ‘mask-to-mask’ – for practically the whole film crew and interviewer, of course, were masked up. I suggested to them that I join in and put one on, but they didn’t fancy that idea much. Still, as you can see, the ‘social distancing’ (even ‘distant socializing’ might be a better phrase:) rules were strictly followed.

Read on…

Cyber-yesteryear – pt. 7: 1997 (Me Lab founded).

Back with more K cyber-nostalgia – this post takes us back to a very special year for the company – the year of its founding! And as you can see from the date on our company registration certificate – that founding took place on June 26, 1997:

And that’s why we have our yearly mega-birthday-bash every June July (don’t ask; what’s a month among friends?!) – only not this year: the first time we’ve ever not had one. Shame. But what can you do?

I remember our first birthday party the following year in 1998, in a fairly rough bowling alley. Not too impressed with such a setting, we made amends the following year – already branching out into the countryside surrounding Moscow, where it’s been every year since, and where I really hope it will be again next year.

Here’s another curious K-tale from the summer of 1997…

Read on…

Exploring Russia: Tourism ÷ lockdown × accelerator = winners’ podium!

Mid-spring this year, at the very peak of the everyone-at-home period, it became obvious that things were looking very bleak for the world, and would stay bleak for a long time. Business would be hard hit, to put it mildly, while the tourism industry would be fairly devastated, with many a business within it not pulling through the crisis. So we at K did what we often always do – put our thinking caps on – and decided… to help out this most badly affected of industries.

Early May I announced that the ‘Kaspersky Exploring Russia’ tourism accelerator had started accepting applications. But I never guessed that more than 500 would be sent in – from 47 countries (nearly a quarter of all the countries in the world!) on five continents (all bar Antarctica!). And looking through them I realized just how much potential there is in the tourism industry – so many ideas, and so many great startups and existing projects. There were no geographical restrictions for applications: they could have – and did – come from anywhere on the planet, but they had to describe tourism ideas that could either tap the potential of Russian tourism or be applied in Russia. We sifted through all the applications to pick a top-10 very best ideas, and those 10 entered the accelerator program.

And for two weeks the 10 projects took part in online master classes and lectures. Each team had a series of specially tailored consultations with mentors. Leading industry figures shared with participants their experiences and know-how for building up a successful business. Mentors included: Vikas Bhola, regional director of Booking.com; Gemma Rubio, founder of Define the Fine; Vadim Mamontov, general director of Russia Discovery; and other industry professionals. And over those two weeks the participants also polished their presentations, which they then gave to the jury, which I was on.

Last week the finalists gave their presentations and answered our questions in the final demo-day of the accelerator. Out of those, we chose three winners, to which were awarded prizes from our partners. Let me tell you a bit about each of them…

First place was taken by 360 Stories. It’s a mobile augmented reality app with a live guide. They say their mission is to ‘modernize the traditional touring experience by powering interactive live tours using real-time guides’. With 360 Stories folks can now remotely roam their favorite cities and attractions by signing up for a personalized touring experience with a real-time local guide.

Btw: 360 Stories nearly lost – by oversleeping and not turning up! Its presentation was given at 05:30 local time – New York. Given such an early rise, Mr. 360 Stories slept in, despite having set his alarm. He wakes up eventually, and calls the organizers to ask why he had 20 missed calls on his phone. They were all to tell him he’d won, and ask – ‘where are you?!’

Read on…

Cyber-tales from the dark side: unexpected vulnerabilities, hacking-as-a-service, and space-OS.

Our first month of summer in lockdown – done. And though the world seems to be opening up steadily, we at K decided to take no chances – remaining practically fully working-from-home. But that doesn’t mean we’re working any less effectively: just as well, since the cybercriminals sure haven’t been furloughed. Still, there’ve been no major changes to the global picture of threats of late. All the same, those cyberbaddies, as always, have been pulling cybertricks out of their hats that fairly astonish. So here are a few of them from last month.

A zero-day in ‘super-secure’ Linux Tails 

Facebook sure knows how to spend it. Turns out it spent a very six-figure sum when it sponsored the creation of a zero-day exploit of a vulnerability in the Tails OS (= Linux, specially tuned for heightened privacy) for an FBI investigation, which led to the catching of a pedophile. It was known for some time beforehand that this deranged paranoiac used this particular – particularly secure – operating system. FB’s first step was to use its strength in mapping accounts to connect all the ones the criminal used. However, getting from that cyber-victory to a physical postal address didn’t work out. Apparently, they ordered development of an exploit for a video-player application. This choice of software made sense as the sex-pest nutcase would ask of his victims’ videos and would probably watch them on the same computer.

It’s been reported that developers at Tails weren’t informed about the vulnerability exploited, but then it turned out that it was already patched. Employees of the company are keeping shtum about all this, but what’s clear is that a vulnerability-to-order isn’t the best publicity. There does remain some hope that the exploit was a one-off for a single, particularly nasty low-life, and that this wouldn’t be repeated for a regular user.

The takeaway: no matter how super-mega-secure a Linux-based project claims to be, there’s no guarantee there are no vulnerabilities in it. To be able to guarantee such a thing, the whole basic working principles and architecture of the whole OS need overhauling. Erm, yes, actually, this is a cheeky good opportunity to say hi to this ).

Hacking-as-a-service 

Here’s another tale-from-the-tailor-made-cyber-nastiness side. The (thought-to-be Indian) Dark Basin cybercriminal group has been caught with its hand in the cyber-till. This group is responsible for more than a thousand hacks-to-order. Targets have included bureaucrats, journalists, political candidates, activists, investors, and businessmen from various countries. Curiously, the hackers from Delhi used really simple, primitive tools: first they simply created phishing emails made to look like they’re from a colleague or friend, cobbled together false Google News updates on topics interesting to the user, and sent similar direct messages on Twitter. Then they sent emails and messages containing shortened links to credential-phishing websites that look like genuine sites, and that was that – credentials stolen, then other things stolen. And that’s it! No complex malware or exploits! And btw: it looks like the initial information about what a victim is interested in always came from the party ordering the cyber-hit.

Now, cybercrime-to-order is popular and has been around for ages. In this case though the hackers took it to a whole other – conveyor – level, outsourcing thousands of hits.

Source

Read on…

Cyber-yesteryear – pt. 6: talking to the media.

Last week I realized I’d been in lockdown-isolation-quarantine for a full quarter-year. Three months sat at home, with only a couple of brief trips to the deserted office, plus every weekend at the dacha with the similarly isolated family. Like for everyone – a very extraordinary daily existence. For me – no planes/airports, no hotels, no meetings or speeches: in short – very little travel.

However, everything’s relative: in three months we’ve all traveled 230+ million kilometers (a quarter of a full orbit of Earth around the sun)! And that’s without taking into account the fact that the Solar System itself travels at some crazy speed. One thing that hasn’t changed much since lockdown began is business meetings – they’ve simply all moved online. Ah yes – and all our business in general is carrying as usual, unaffected by biological viruses ).

But enough lockdown talk; you’re probably tired of hearing anything in connection with it. Accordingly, herewith, I continue with more of my tales from the cyber-past side; this time – interviews with newspapers, magazines, radio, TV, plus assorted other public performances. (I was reminded of my ‘media relations’ activity while recalling my week of interview-hell at CeBIT long ago the other day when compiling my CeBIT recollections (Cyber-yesteryear, pt. 4). And it turns out I’ve plenty to relate to you about interesting experiences talking to the media and public speaking and all that – plenty that’s fun and unusual, plus of course a few (brightened and polished) photos too.

And there’ll be all sorts of different sizes and flavors of media-tales coming up too: from speeches in practically empty halls – to rammed stadiums! From unknown tiny local media publications – to top-tier global media household-name conglomerates! From professional lectures at leading universities and/or with specially tech-equipped audiences – to informal lectures about the wonders of arithmetic on a ship sailing to… Antarctica via Drake Passage! Eugene is the name; variation is the game ).

Right. I guess the logical place to begin is right at the start…

Read on…

Cyber hygiene: essential for fighting supply chain attacks.

Hi folks!

Quite often, technical matters that are as clear as day to techie-professionals are somewhat tricky to explain to non-techie-folks. Still, I’m going to have a go at doing just that here today. Why? Because it’s a darn exciting and amazingly interesting world! And who knows – maybe this read could inspire you to become a cybersecurity professional?!…

Let’s say you need to build a house. And not just a standard-format house, but something unique – custom-built to satisfy all your whims and wishes. First you need an architect who’ll draw up the design based on what you tell them; the design is eventually decided upon and agreed; project documentation appears, as does the contractor who’ll be carrying out the construction work; building inspectors keep an eye on quality; while at the same time interior designers draw up how things will look inside, again as per your say-so; in short – all the processes you generally need when constructing a built-to-order home. Many of the works are unique, as per your specific instructions, but practically everything uses standard materials and items: bricks, mortar, concrete, fixtures and fittings, and so on.

Well the same goes for the development of software.

Many of the works involved in development are also unique, requiring architects, designers, technical documentation, engineer-programmers… and often specific knowledge and skills. But in the process of development of any software a great many standard building bricks libraries are used, which carry out all sorts of ‘everyday’ functions. Like when you build a house – you build the walls with standard bricks; the same goes for software products: modules with all sorts of different functionalities use a great many standardized libraries, [~= bricks].

Ok, that should now be clear to everyone. But where does cybersecurity come into all of this?

Well, digital maliciousness… it’s kinda the same as house-building construction defects – which may be either trivial or critical.

Let’s say there’s some minor damage done to a completed house that’s ready to move into, which isn’t all that bad. You just remedy the issue: plaster over, re-paint, re-tile. But what if the issue is deep within the construction elements? Like toxic materials that were used in construction in the past? Yes, it can become expensive painful.

Well the same goes for software. If a contagion attaches itself to the outside, it’s possible to get rid of it: lance it off, clean up the wound, get the software back on its feet. But if the digital contamination gets deep inside – into the libraries and modules [= bricks] out of which the final product [house] is built… then you’ve got some serious trouble on your hands. And it just so happens that finding such deep digital pestilence can be reeeaaally tricky; actually extracting the poison out of the working business process – more so.

That’s all a bit abstract; so how about some examples? Actually, there are plenty of those. Here are a few…

Even in the long-distant past, during the Windows 98 era, there was one such incident when the Chernobyl virus (also called CIH, or Spacefiller) found its way into the distributions of computer games of various developers – and from there it spread right round the world. A similar thing happened years later in the 2000s: a cyber-infection called Induc penetrated Delphi libraries.

Thus, what we have are cyberthreats attacking businesses from outside, but also the more serious threats from a different type of cyber-disease that manages to get inside the internal infrastructure of a software company and poison a product under development.

Let’s use another figurative example to explain all this – a trip to your local supermarket to get the week’s groceries in… during mask-and-glove-wearing, antiseptic-drenching lockdown!… Yes, I’m using this timely example as I’m sure you’ll all know it rather well (unless you’re the Queen or some other VIP, perhaps live off the land and don’t use supermarkets… but I digress).

So yes: you’ve grabbed the reusable shopping bags, washed your hands for 20 seconds with soap, donned the faced mask, put the gloves on, and off you go. And that’s about it for your corona-protective measures. But once you’re at the supermarket you’re at the mercy of the good sense and social responsibility and sanitary measures of the supermarket itself plus every single producer of all the stuff that you can buy in it. Then there are all the delivery workers, packing workers, warehouse workers, drivers. And at any link in this long chain, someone could accidentally (or on purpose) sneeze right onto your potatoes!

Well it’s the same in the digital world – only magnified.

For the supply chain of modern-day ‘hybrid’ ecosystems of IT development is much, much longer, while at the same time we catch more than 300,000 brand new cyber-maliciousnesses EVERY DAY! What’s more, the complexity of all that brand new maliciousness itself is rising constantly. To try and control how much hand-washing and mask-and-glove wearing is going on at every developer of every separate software component, plus how effective cyber-protection systems of the numerous suppliers of cloud services are… – it’s all an incredibly difficult task. Even more difficult if a used product is open-source, and its assembly is fashionably automated and works with default trust settings and on-the-fly.

All rather worrying. But when you also learn that, of late, attacks on supply chains happen to be among most advanced cyber-evil around – it gets all rather yikes. Example: the ShadowPad group attacked financial organizations via a particular brand of server-infrastructure management software. Other sophisticated cybercriminals attack open source libraries, while our industry colleagues have reminded us that developers are mostly unable to sufficiently verify that components they install that use various libraries don’t contain malicious code.

Here’s another example: attacks on libraries of containers, like those of Docker Hub. On the one hand, using containers makes the development of apps and services more convenient, more agile. On the other, more often than not developers don’t build their own containers and instead download ready-made ones – and inside… – much like a magician’s hat – there could be anything lurking. Like a dove, or your car keys that were in your pocket. Or a rabbit. Or Alien! :) ->

Read on…