Many firms hit by global cyber-attacks

Ok. The "red screen" is a SmartScreen" detection, I beleive. Again, MS would have had a file hash by the time you tested. Also supposedly WD will perform cloud scanning at .exe run time if option enabled in WD. Never seen an exploit detection by WD so don't know if it uses the same display screen as SmartScreen.

-EDIT- One way to know for sure is disable Win 10 native SmartScreen. Then see if WD catches it.

 

Eset thinks the "culprit" is TeleBots: https://www.welivesecurity.com/2017/06/30/telebots-back-supply-chain-attacks-against-ukraine/

 

I haven't been able to free up the space to test it but seems others are a lot farther along anyway.

Specifically on this end I am on the hunt for the technique itman posted about a "novel idea" of interrupting the flow of the WMI connection with Consumer Event.

All I found that comes close so far is this from a Fire Eye page here.

The MBR Petya ordeal is one matter and the study of the persistence and timer aspect of it another of great interest and importance.

 

Looks pretty convincing -- Kudos to ESET for its detective work.

hawki still has his doubts. hawki's analysis causes him to have lingering suspicions that the actual bad actor is a 400 pound guy who lives in the basement of his mother's house in Gary, Indiana who launched NotPetya, disguised as a charade-TeleBots attack, as a distraction while he searches for BlockBuster Video Stores to install POS scanners.

In other words: Because of the suspect recent history and current state of its target and neighboring areas, the very sophistication of this attack and its possible international state or state-associated actor implications and fallout, one needs to be leary of such "clear" markers that could very well be deliberate false flags. There are numerous scenarios, obvious and not so obvious, of who would want this attack to appear to have been orchestrated by the Telebots and why.

 

Of note is that this recent incident was not the first time that M.E. Doc software has been hacked. Again for me something is very wrong with security QC procedures in the Ukraine.

 

Eset believes TeleBots is a "morphing" of the BlackEnergy group: https://www.welivesecurity.com/2016/12/13/rise-telebots-analyzing-disruptive-killdisk-attacks/ . BlackEnergy has been around for a long time; since 2007: https://www.welivesecurity.com/2016...tacks-ukrainian-news-media-electric-industry/

All points to a state-sponsored actor. Hum ........ who has a big problem with the Ukraine presently?

 

Russia was suggested within a few hours of the start of the attacks.

 

I doubt the real truth will ever be made public, just speculation.

 

Remember when North Korea was at the top of the list when WannaCry first appeared? So, given the similarities, how many suspects now? Oh yeah, the real truth had better come out, I WannaKnow.

 

US-CERT Alert (TA17-181A) - Petya Ransomware

Original release date: July 01, 2017

"...The scope of this Alert’s analysis is limited to the newest “Petya” variant that surfaced June 27, 2017, and this malware is referred to as “Petya” throughout this Alert...."

https://www.us-cert.gov/ncas/alerts/TA17-181A

 

Actually, the only interesting thing to me was the hacked update server. That's why I would advice to never use auto-update on any app. And that's why I always monitor even trusted apps for suspicious behavior with HIPS.

 

But there is something uncommon in the malware itself that no one seems to be talking about (She writes mysteriously)...

 

If you are not very intimately familiar with program updates and their intended behaviors\run sequences, then how would you be able to identify one that is malicious ?

You cannot know what a new program update is intended to do and 99.9 % of the time HIPS alerts are not going to give any indication of malicious behavior (you must be able to spot it).

The only way to get familiar with program updates using SpyShelter is to set it to "Ask User" and keep all modules enabled. Then you must familiarize yourself with malware behaviors by actually testing malware yourself on a continual basis.

Not trusting program updates is so impractical that you might as well just turn off your PC.

 

I'm not following you. I have been manually updating apps for years, and of course if the server is hacked you will still download malware instead of the legitimate app, but at least you will get a chance to react, since HIPS won't auto-trust newly downloaded software. I'm not so sure if it will be able to spot malicious behavior when auto-update is being used.

Weird statement, isn't that the whole point of HIPS, to alert about abnormal behavior? It's actually very easy to spot, because most apps won't trigger certain behavior. If I update my browser, and all of a sudden it wants to inject code, run powershell.exe and modify protected files, then surely there must be a problem?

Quit teasing us.

 

Assume HIPS training mode had been previously employed. HIPS was then switched to interactive mode. It would be rare that any subsequent application update would trigger an alert. It is possible that a new process for the app was created and the like. However, this would be in all likelihood stored in a previously created directory so nothing abnormal so far.

The new or updated process could be validated against the update release notes issued by vendor for starters. Additionally, existing HIPS rules could be referred for the application to determine if the new/updated process is performing activities not previously observed; e.g. starting PsExec, etc..

The main point is that all this should have been done on a test device with the existing application installed. Application behavior and functionality would then be validated against previously created benchmark criteria. Obviously, process event activity logging would be part of that criteria. Only after all the previous are validated would the update be rolled out to the endpoints. This procedure is SOP in most large gov. and commercial entities in the U.S.. Regardless of HIPS usage on the test device, it would have become obvious that something was wrong with the update.

-EDIT- The above is "overkill" for the average individual user. Best mitigation is just restoring from an image backup.

 

Perhaps that it was "disguised" ransomware and its real purpose was to adversely affect the target's internal operations.

 

Simple to understand wise words.

 

Man... I just dislike forum posts because they are not normal human conversations. And to make them anywhere like a normal human conversation is just way too much work.

Because of the limitations of forum posts, so much stuff gets miscommunicated or misinterpreted.

It's possible that you would be able pick-off something in a HIPS alert that is malicious. It would be off-the-wall behavior for the program - such as *.dll injection, trying to take a screenshot, installing hooks, etc - depending upon what that program customarily does.

Not really. HIPS just alerts to events according to its detection capabilities and per existing rules.

The user has to differentiate between the good (allow), the bad (block\terminate), and the unknown (coin toss for the uninformed and block for those that know better).

What I was getting at was a person who uses HIPS needs to practice, at least for a while, in full-blown interactive mode to familiarize themselves with what is on their system and what it is doing. With that awareness, a user can pick-off malicious stuff. However, those that adhere to this learning are extremely rare.

HIPS is a great learning tool. With the knowledge one gains from using HIPS, one has much better awareness.

As you know, I use SpyShelter FW - and I very often delete all the created rules and always run in "Ask User" mode. Jumping around from test system to test system, constantly using different softs, constantly testing different malware, the HIPS and logging are valuable tools.

@itman 's linked articles are good malware behavior learning resources in addition to actual practice with malware.

 

Not to mention that in home environments SMB is rarely used. How many people have heard of it?

People are more likely to get infected through opening a phishing e-mail than through a backdoor exploit or drive-by download.

 

SMB = small-medium business L0L

 

Now we know why hackers target corporate environments... whether its to get money, sabotage a competitor, malicious mischief or whatever, its too tempting to resist breaking into.

 

SMB in Windows-speak = server message block

 

Let's "tighten up" one last "loose end" in regards to this attack.

In the previous posted MRG link, it identified four attack vectors:

Let's talk in detail about attack vector no. 4. Carbon Black has done a detailed analysis on that that is definitely worth a read:

https://www.carbonblack.com/2017/06...technical-analysis-petya-notpetya-ransomware/

The main point to note is that PsExec was downloaded and used to remotely executed the malware:

If the PsExec execution fails, the malware will then use WMIC:

 

I always knew this sort of hijack could one day happen even back on Windows 98SE and is exactly why I always been skeptical of the so called network (Cloud/Remote) routine.

There was that raw gnawing away that What IF, this same type of hijack happened to any widely used product update?

Stranger things have happened with these electro-data toys.

Another useful read to delve right up (or in) to the point of contact. Appreciate the details.

So many built-in avenues were made available for things like this to finally come to light. Wow.