North Korea-linked Lazarus APT group is extending its operations and started targeting the IT supply chain on new targets.

North Korea-linked Lazarus APT group is now targeting also IT supply chain, researchers from Kaspersky Lab warns.

The activity of the Lazarus APT group surged in 2014 and 2015, its members used mostly custom-tailored malware in their attacks. This threat actor has been active since at least 2009, possibly as early as 2007, and it was involved in both cyber espionage campaigns and sabotage activities aimed to destroy data and disrupt systems.

The group is considered responsible for the massive WannaCry ransomware attack, a string of SWIFTattacks in 2016, and the Sony Pictures hack.

The APT group used a new variant of the BLINDINGCAN backdoor in attacks aimed at a Latvian IT vendor and a South Korean think tank, respectively in May and June.

The nation-state actor used its multi-platform malware framework MATA framework.

The MATA malware framework could target Windows, Linux, and macOS operating systems, the malware framework implements a wide range of features that allow attackers to fully control the infected systems.

According to the experts from Kaspersky that first analyzed the framework, the MATA campaign has been active at least since April of 2018.

Kaspersky experts reported that the Lazarus APT is building supply-chain attack capabilities with an updated DeathNote (aka Operation Dream Job) malware cluster that is an updated variant of the BlindingCan RAT. The use of the BlindingCan RAT was first documented by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) in August 2020. The BlindingCan was employed in attacks on US and foreign companies operating in the military defense and aerospace sectors.

The BLINDINGCAN RAT implements the following built-in functions-:

• Retrieve information about all installed disks, including the disk type and the amount of free space on the disk
• Get operating system (OS) version information
• Get Processor information
• Get system name
• Get local IP address information
• Get the victim’s media access control (MAC) address.
• Create, start, and terminate a new process and its primary thread
• Search, read, write, move, and execute files
• Get and modify file or directory timestamps
• Change the current directory for a process or file
• Delete malware and artifacts associated with the malware from the infected system

The CISA MAR provided indicators of compromise (IoCs), Yara rules, and other technical info that could be used by system administrators to discover compromise systems within their networks.

“Our investigation revealed indications that point to Lazarus building supply-chain attack capabilities. In one case, we found that the infection chain stemmed from legitimate South Korean security software executing a malicious payload; and in the second case, the target was a company developing asset monitoring solutions in Latvia, an atypical victim for Lazarus.” reads the report published by Kaspersky.

This is the first IT supply chain attack conducted by Lazarus that was documented by Kaspersky researchers.

Ariel Jungheit from Kaspersky’s Global Research and Analysis Team (GReAT) explained the dangers of supply chain attacks like the SolarWinds hack and warned of nation-state actors investing in such capabilities.

“When carried out successfully, supply chain attacks can cause devastating results, affecting much more than one organization – something we saw clearly with the SolarWinds attack last year,” Jungheit said. “With threat actors investing in such capabilities, we need to stay vigilant and focus defense efforts on that front.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, supply chain attack)

We decrypt Cobalt Strike traffic using one of 6 private keys we found.

In this blog post, we will analyze a Cobalt Strike infection by looking at a full packet capture that was taken during the infection. This analysis includes decryption of the C2 traffic.

If you haven’t already, we invite you to read part 1 first: Cobalt Strike: Using Known Private Keys To Decrypt Traffic – Part 1.

For this analysis, we are using capture file 2021-02-02-Hancitor-with-Ficker-Stealer-and-Cobalt-Strike-and-NetSupport-RAT.pcap.zip, this is one of the many malware traffic capture files that Brad Duncan shares on his web site Malware-Traffic-Analysis.net.

We start with a minimum of knowledge: the capture file contains encrypted HTTP traffic of a Cobalt Strike beacon communicating with its team server.

If you want to know more about Cobalt Strike and its components, we highly recommend the following blog post.

First step: we open the capture file with Wireshark, and look for downloads of a full beacon by stager shellcode.

Although beacons can come in many forms, we can identify 2 major categories:

1. A small piece of shellcode (a couple of hundred bytes), aka the stager shellcode, that downloads the full beacon
2. The full beacon: a PE file that can be reflectively loaded

In this first step, we search for signs of stager shellcode in the capture file: we do this with the following display filter: http.request.uri matches “/….$”.

We have one hit. The path used in the GET request to download the full beacon, consists of 4 characters that satisfy a condition: the byte-value of the sum of the character values (aka checksum 8) is a known constant. We can check this with the tool metatool.py like this:

More info on this checksum process can be found here.
The output of the tool shows that this is a valid path to download a 32-bit full beacon (CS x86).
The download of the full beacon is captured too:

And we can extract this download:

Once the full beacon has been saved to disk as EbHm.vir, it can be analyzed with tool 1768.py. 1768.py is a tool that can decode/decrypt Cobalt Strike beacons, and extract their configuration. Cobalt Strike beacons have many configuration options: all these options are stored in an encoded and embedded table.

Here is the output of the analysis:

Let’s take a closer look at some of the options.

First of all, option 0x0000 tells us that this is an HTTP beacon: it communicates over HTTP.
It does this by connecting to 192.254.79[.]71 (option 0x0008) on port 8080 (option 0x0002).
GET requests use path /ptj (option 0x0008), and POST requests use path /submit.php (option 0x000a)
And important for our analysis: there is a known private key (Has known private key) for the public key used by this beacon (option 0x0007).

Thus, armed with this information, we know that the beacon will send GET requests to the team server, to obtain instructions. If the team server has commands to be executed by the beacon, it will reply with encrypted data to the GET request. And when the beacon has to send back output from its commands to the team server, it will use a POST request with encrypted data.

If the team server has no commands for the beacon, it will send no encrypted data. This does not necessarily mean that the reply to a GET request contains no data: it is possible for the operator, through profiles, to masquerade the communication. For example, that the encrypted data is inside a GIF file. But that is not the case with this beacon. We know this, because there are no so-called malleable C2 instructions in this profile: option 0x000b is equal to 0x00000004 -> this means no operations should be performed on the data prior to decryption (we will explain this in more detail in a later blog post).

Let’s create a display filter to view this C2 traffic: http and ip.addr == 192.254.79[.]71

This displays all HTTP traffic to and from the team server. Remark that we already took a look at the first 2 packets in this view (packets 6034 and 6703): that’s the download of the beacon itself, and that communication is not encrypted. Hence, we will filter these packets out with the following display filter:

http and ip.addr == 192.254.79.71 and frame.number > 6703

This gives us a list of GET requests with their reply. Remark that there’s a GET request every minute. That too is in the beacon configuration: 60.000 ms of sleep (option 0x0003) with 0% variation (aka jitter, option 0x0005).

We will now follow the first HTTP stream:

This is a GET request for /ptj that receives a STATUS 200 reply with no data. This means that there are no commands from the team server for this beacon for now: the operator has not issued any commands at that point in the capture file.

Remark the Cookie header of the GET request. This looks like a BASE64 string: KN9zfIq31DBBdLtF4JUjmrhm0lRKkC/I/zAiJ+Xxjz787h9yh35cRjEnXJAwQcWP4chXobXT/E5YrZjgreeGTrORnj//A5iZw2TClEnt++gLMyMHwgjsnvg9czGx6Ekpz0L1uEfkVoo4MpQ0/kJk9myZagRrPrFWdE9U7BwCzlE=

That value is encrypted metadata that the beacon sends as a BASE64 string to the team server. This metadata is RSA encrypted with the public key inside the beacon configuration (option 0x0007), and the team server can decrypt this metadata because it has the private key. Remember that some private keys have been “leaked”, we discussed this in our first blog post in this series.

Our beacon analysis showed that this beacon uses a public key with a known private key. This means we can use tool cs-decrypt-metadata.py to decrypt the metadata (cookie) like this:

We can see here the decrypted metadata. Very important to us, is the raw key: caeab4f452fe41182d504aa24966fbd0. We will use this key to decrypt traffic (the AES adn HMAC keys are derived from this raw key).

More metadata that we can find here is: the computername, the username, …

We will now follow the HTTP stream with packets 9379 and 9383: this is the first command send by the operator (team server) to the beacon:

Here we can see that the reply contains 48 bytes of data (Content-length). That data is encrypted:

Encrypted data like this, can be decrypted with tool cs-parse-http-traffic.py. Since the data is encrypted, we need to provide the raw key (option -r caeab4f452fe41182d504aa24966fbd0) and as the packet capture contains other traffic than pure Cobalt Strike C2 traffic, it is best to provide a display filter (option -Y http and ip.addr == 192.254.79.71 and frame.number > 6703) so that the tool can ignore all HTTP traffic that is not C2 traffic.

This produces the following output:

Now we can see that the encrypted data in packet 9383 is a sleep command, with a sleeptime of 100 ms and a jitter factor of 90%. This means that the operator instructed the beacon to beacon interactive.

Decrypted packet 9707 contains an unknown command (id 53), but when we look at packet 9723, we see a directory listing output: this is the output result of the unknown command 53 being send back to the team server (notice the POST url /submit.php). Thus it’s safe to assume that command 53 is a directory listing command.

There are many commands and results in this capture file that tool cs-parse-http-traffic.py can decrypt, too much to show here. But we invite you to reproduce the commands in this blog post, and review the output of the tool.

The last command in the capture file is a process listing command:

Conclusion

Although the packet capture file we decrypted here was produced more than half a year ago by Brad Duncan by running a malicious Cobalt Strike beacon inside a sandbox, we can decrypt it today because the operators used a rogue Cobalt Strike package including a private key, that we recovered from VirusTotal.

Without this private key, we would not be able to decrypt the traffic.

The private key is not the only way to decrypt the traffic: if the AES key can be extracted from process memory, we can also decrypt traffic. We will cover this in an upcoming blog post.

About the authors
Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center senior handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.

You can follow NVISO Labs on Twitter to stay up to date on all our future research and publications.

A cyberattack has disrupted gas stations from the National Iranian Oil Products Distribution Company (NIOPDC) across Iran.

A cyber attack has disrupted gas stations from the state-owned National Iranian Oil Products Distribution Company (NIOPDC) across Iran. The attack also defaced the screens at the gas pumps and gas price billboards.

In multiple cities, the billboards were displaying messages like “Khamenei! Where’s our fuel?” and “Free gas at [local gas station’s name].”

After the attack, the screens at the impacted NIOPDC gas stations were showing the words “cyebrattack 64411,” which is the phone number for the office of Supreme Leader Ayatollah Ali Khamenei.

NIOPDC currently manages more than 3,500 gas stations across the country.

The operations at the gas pumps were interrupted immediately after the incident because the employees were not able to charge customers for the fuel they were buying.

At this time, no one claimed responsibility for the attack, but Iranian authorities speculate the incident was the result of a cyber attack orchestrated by a foreign, hostile state.

The Iranian TV confirmed that the root cause of the incident is a nationwide cyber-attack that targeted petrol stations.

The message “cyberattack 64411” was also shown on the billboards of Iranian train stations during another attack that took place in July and that hit Iran’s railroad system.

A Ministry of Oil spokesperson downplayed the news of a “cyberattack” and stated that the incident was caused by a software glitch.

At the time of this writing, the operations at the gas stations have resumed.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Iran)

The post Operations at Iranian gas stations were disrupted today. Cyber attack or computer glitch? appeared first on Security Affairs.

Not sure why Microsoft keep making screwing those patches.

Here's details about the bug - https://github.com/klinix5/ProfSvcLPE/blob/main/write-up.docx

PoC - https://github.com/klinix5/ProfSvcLPE/tree/main/DoubleJunctionEoP

This bug require another user password that's different from the current one, I'm not sure. But it might be possible to do it without knowing someone else password.
The PoC must be tested with standard user privileges with another standard user password. If it succeeds, it will spawn a SYSTEM shell.

At the time of writing this, this vulnerability affects every server and desktop edition including 11 and server 2022.

In April 2021, I discovered a security flaw in Windows Recovery Environment Agent which allowed an unauthenticated attacker to gain elevated access to a windows machine in a locked state.

Those research were based on Jonas findings related to bypassing lockscreen (you can find more here - https://twitter.com/jonaslyk/status/1301245145568997376?lang=en). He described a flaw, which allowed lock screen bypass using Ease of Access feature.

Looking at CVE-2020-1398, the bug existed in sticky keys pop-up 

By clicking the link, an instance of settings will be spawned in the background. Then you’ll be simply able to bypass the lockscreen. Microsoft has patched the issue by removing the link as it no longer appears when being spawned in a lockscreen environment.

And to be clear this bug and its descendants need a condition. On Windows 10 machine, at least one user must have a Microsoft account linked to his local account. Otherwise, the bug isn't exploitable.

Now, I'll try to give a short explanation for you humans. Cause if I showed the video PoC you will be confused as hell.

I have noticed a weird kind of behaviour when typing a wrong password, a small arrow next to the email address will be visible.
This behaviour exists for some unknown reason, maybe a bug ? feature ? probably a bug.(apparently its a feature after the patch)

Clicking there will take us to another page.As we can see that we’re allowed to login with another email address or even creating a new account.

I tried to create a new account, login with it but it fails since the account doesn’t belong to the one we are trying to reset its password.

However, this small button right there attracted my attention and hmmm it's interesting

By clicking on it we’ll see another pop-up dialogue, that has a link on it.

Hmmm very interesting, a link ? in the lockscreen ? weird right. As usual, we’ll click on it and see what happen… clicking on it did absolutely nothing, BUT maybe something was spawned in the background and we can’t see it, as Jonas described in his lockscreen bypass, he used to enable narrator in order to navigate in background apps. I enabled narrator and got some very interesting results.

When enabled and I click on the button, you can hear narrator saying “how do you want to open this”, and narrator’s focus is on something else not in Microsoft account window. We spawned an “Open With” window with narrator’s focus on it in the background; Typically the “Open With” window looks like this

But only has two options the first is MS Edge and the second one is Internet explorer, we’ll dig with MS Edge since it’s selected by default, please NOTE that you might to HOLD Caps lock while using arrow keys to navigate.

After tests, as soon as we select OK we lose narrator’s focus and we’re no longer able to control background window.

We can have narrator’s focus again as soon as we repeat steps described above, we’ll have narrator’s focus again. But this time we’ll have it on MS Edge browser, at this point, we will need to elevate our privileges, the only way I can think of to execute arbitrary commands is to spawn a settings instance. This can be done by spawning another a new InPrivate window, (please NOTE: you won’t be able to see any of those, and things will be completely invisible you must use your ear to hear what narrator say and use it to navigate);

Then you might need to go on “More details”

Press enter and navigate to settings

Which will redirect us to another page, keep navigating until you reach “Windows Diagnostic data setting” and then navigate using narrator to open and click enter again

In settings navigate to “Home” and press enter

Then navigate to “Devices”

Navigate to Autoplay->Choose Autoplay Defaults->”Open folder to view files(File explorer)

At this point, you might need to plug a USB device into the device. As soon as plugged narrator will have his focus on file explorer, now you can execute anything in the USB.
In order to verify our findings, I made a simple batch script which will verify our findings

mkdir c:\poc
whoami /all >  c:\poc\whoami.log

And after the execution, we can observe a success

Elevating privileges is easy since we’re marked as “NT AUTHORITY\Authenticated Users” as the majority of EoPs are reachable from those privileges.

PoC - https://youtu.be/9rXXfWN0h6A

(Also, looking for some opportunities to study computer science in UK or anywhere else, if you can help reach me out on my twitter.)

(click for better images quality)

I always wanted to start this series, executing code inside antiviruses security agents. 

People always underestimated Ring 3 code execution, as it seems to be useless in case of a cyber attack. The AV agents usually defeat the malware before it starts doing serious damage, unlike being in ring 0, attackers just override callbacks and hooks and proceed to do whatever they want.

 However, those hooks were never made to block trusted agents actions. So in the majority of cases, executing code in the context of an antivirus agent will bypass the hooks.

I'll first of all start with windows defender, it's technically the easiest one. In order to achieve the objective of executing code in the context of the antivirus service "MsMpEng.exe" we will need the following things as a requirement.

1. Shutting down windows defender antivirus

You can see in process explorer that windows defender is running without PsProtectedSignerAntimalware-Light which makes the next step easier!

3. Executing arbitrary code in windows defender protection engine

This was the most challenging problem, Microsoft actually did a great job protecting the process even if PsProtectSignerAntimalware-Light was disabled.

Classic process injection techniques didn't work as expected, cause windows defender kernel-mode driver kicks in. This feature is also known as "Tamper-Protection" which prevents any unattended injections to any user-mode windows defender service.

And unfortunately, I had to move to DLL hijack bugs to get this done. Shame...

I run into an issue, actually, Microsoft implemented a hard to bypass mitigation ProcessSignaturePolicy which was a serious challenge. So in conclusion we can't inject code nor inject DLLs nor hijack antimalware executables (such as DLLs).

Unfortunately, Microsoft allowed a little flaw there. As trustedinstaller or any process with SeRestorePrivelege enabled we're allowed to have write access to C:\ProgramData\Microsoft\Windows Defender\Platform <- this folder contains windows defender executable with some DLLs. I noticed through reverse engineering that the ProcessSignaturePolicy isn't enabled till all windefend dlls are loaded. Which means if we get a DLL loaded at the process initialization we can have arbitrary code execution inside windows defender process. I also noticed that there's a tiny flaw in the dll load behaviour.

Before windows defender load dlls, it attempts to verify the integrity of the file using WinVerifyTrusted, I noticed a tiny flaw in this functionality.

As soon as Windows defender start it will query 

C:\ProgramData\Microsoft\Windows Defender\Platform for folders and will determine the working directory based on string version, let's take by example the directory query returns the following result

4.18.2106.6-0

4.18.2107.4-0

4.18.2108.2-0

Windows Defender in this case will use 4.18.2108.2-0 which is the latest version.

And to be honest that's very design for an antivirus and if I were Microsoft I'll definitely consider fixing this.

First of all, why ? 

Everything I am doing has a why, Microsoft bug bounty program is trash. They ignore or just doesn't care enough to review correctly my cases.

The Timeline:

So recently I've doing some research in google omaha updater, I created some mini tools to communicate with service and to do some tasks. What I've noticed that google omaha is looking for a non existing configuration file "C:\GoogleUpdate.ini" which got my interest. The file seems to be used mainly for logging/debugging detail as described here, and since the service run as a privileged component and accessible to non-admin guys it might be an interesting area to do research with.

A lot of you will say that "C:\" doesn't allow users by default to create new files there, but starting from windows 10 2009 it seems to be allowing authenticated users to write there by default and some DACL changes was done there, the following images were taken from a default windows installation.

If you're asking about windows server, no the C:\ doesn't allow non admin to create files there.

You can guess we already got our arbitrary file overwrite there but does it stop here ? Unfortunately no, looking again at the structure of the there's a "MaxLogFileSize" parameter that take a file size and it can be 0. Looking at the implementation there's a DACL write every time google omaha tries to create a new file allowing "authenticated users" to have write access according to this code snippet.

Now the only thing that remain is starting the service itself, it's easy since I used to do that when I was writing some google omaha tools, you can just call CoCreateInstance and make sure to pass google updater CLSID and hurrai the service started as system.

I written a simple PoC that demonstrate file take over for both google update service and Microsoft Edge Update Service it can be found here.

My twitter.

 (Click to enlarge)

Days ago, as usual I was reading some google project zero bugs. Then I found this one by James Forshaw about an EoP in dos device when a privileged process impersonate the user to load libraries. You can read the article here , My only problem was the PoC file as it seems look like james submitted 2 attachment to MSRC, the first one was with the actual PoC compiled and a dll, the second attachment seems to be password protected

And after some research trying to find the original PoC source code, I didn't found something useful so the only way to answer my questions is to reverse the actual PoC.

I really had some questions like, how did he managed the override the original link ? how did he get the login session \Sessions\0\DosDevices\X-Y <- how did he manage to get those numbers ?

Nothing special the dll will just call "RevertToSelf()" and then create notepad as a child process.

But for the actual PoC, some ops are done. I will only cover the code which has impact on our research area.

The PoC will first check the current OS architecture if it match x86 it will continue otherwise it will exit. I still don't know why did he do that but maybe to get ride off the annoying Wow64 redirections.

And after doing some reverse I finally answered my question, in order to get the current DosDevice path is to call GetTokenInformation

Then simply it will redirect the dos device symlink to the PoC's current directory by calling NtCreateSymbolicLinkObject, of course it make sure to recreate C:\Windows\System32 and place the dll described previously to system32 with the name PrintFilterPipelinePrxy.dll, after that the PoC will simply call "OpenPrinterW" "StartDocPrinterW" "EndDocPrinter" then the dll will be loaded as the spooler service. Microsoft has released the advisory for the bug as CVE-2015-1644

Quite easy, but is it exploitable ? Well yes but actually no. In some rare cases the CreateFileW redirection might be useful. For now I just wanna fix one problem, I didn't like how the PoC call GetTokenInformation to get the current process Dos Device so I've done some research and got some good result.

You won't need to create the actual DosDevice link, overriding C:\ will do the job for the current user.

I was firstly inspired by sandbox escaper arbitrary file read PoC, which was dropped as a 0day vulnerability 2018. The bug existed in MsiAdvertiseProduct function, calling it will trigger a file copy from windows installer service running as SYSTEM privileges.

In this vulnerability I will be attacking the MsiInstallProduct which takes two arguments. 

The first one is szPackagePath which can be either an URL or a local file. The second parameter is szCommandLine.

After calling the function, I had the following output from process monitor

Phase 1: Windows installer service will impersonate the user and call OpenAndValidateMsiStorageRec which will first check if the package valid.

Phase 2: Windows installer service will reverse to itself and create a new file in C:\Windows\Installer\*.msi

Phase 3: It will make sure that the opened file match the expected file to be opened by calling GetFinalPathNameByHandleW if it match the file will be copied if it doesn’t the installer service will impersonate the user and try to copy the file.

The flaw exist exactly in msi.dll!CopyTempDatabase() when it call   CElevate::CElevate((CElevate *)&X, 1); to elevate privileges instead of staying in impersonation mode

There’s some checks in CopyTempDatabase such as CMsiFileCopy::VerifySource which check the source if it valid for for copy or not but it can be defeated if the user impersonation is done incorrectly.

Since the package sanitization will run while impersonating the user, we can redirect it with the trick mentioned above to a valid package which will trick OpenAndValidateMsiStorage and mark it as a valid package. Then the installer will check if the target file is the one expected to be opened in our case yes it is so it will proceed copying the file to C:\Windodws\Installer\*.msi

I succeeded implementing the exploit but I had one more issue, when the file is copied to C:\Windows\installer it’s probably not the only file there so fetching the newly created file is like a programming quiz, I took a while to see my options, the first one was ReadDirectoryChangesW which wait and fetch any newly created file, this sounds great but wasn’t useful. Since windows installer service tamper with certain parameters of the directory and remove the newly created MSI package as soon as it’s written. The second option was to use FindFirstFileW, FindNextFileW which has solved a bit of the problem, the technique I used here is to find newest file created and pick it as the our target, for some unknow reasons the technique failed and always pick the wrong file. So I moved away to another technique (and it was my last hope), This snippet of code will explain the process of finding the newly created file

We will first begin by deprecating “C:\” path and we will use the windows GUI path so we won’t issues with redirection, to retrieve the GUI path of drive you can use GetVolumeNameForVolumeMountPoint, then it will be used primary in the next api calls. Next our PoC will search \Windows\Installer\*.msi and will store it in an array “first_srch[10000]” and then you might notice there’s two calls of FindFirstChangeNotification and according to Microsoft documentation

“Creates a change notification handle and sets up initial change notification filter conditions. A wait on a notification handle succeeds when a change matching the filter conditions occurs in the specified directory or subtree. The function does not report changes to the specified directory itself. “

The PoC will set 2 events, one for the file creation and the second one for file write, When the first event trigger the PoC will restart the search of MSI files and will store to an array, the PoC will take those arrays and compare every file name if there’s something that doesn’t match at certain index then it’s the newly created file. After that we will just wait the second event to trigger then simply copy our file.

How exploitable a windows read-file ?

When windows crash it automatically generate a windows kernel memory dump in C:\Windows\memory.dmp and restrict it’s DACL to administrators only

I recently discovered a bench of bugs windows appx, I've reported some of them and even some of them were considered as useless since this one require at least 2 active partitions to work so it's kinda an uncommon attack scenario. So instead of keeping them in my pc for no reason or reporting them to msrc I will drop them here.

Steps to reproduce:

1. Run the poc and give it the target drive as an argument.
2. It will spawn an instance of storage settings.
3. Then go to "change were new content is saved" and change it to the target drive.
4. Press enter in the poc
5. After few seconds the spooler service will have a child process "notepad.exe" running with system privileges.

After my previous disclosure with Windows defender and Windows Setup, this is the next one

First of all, why ? it’s because I can, and because I need a job.

In this blog I will be disclosing about 8 0-day vulnerability and all of them are still unknow to the vendors, don’t expect those bugs to be working for more than a week or two cause probably they will release an emergency security patches to fix those bugs.

    Avast antivirus

a.   Sandbox Escape

So avast antivirus (any paid version) have a feature called Avast sandbox, this feature allow you to test suspicious file in sandbox. But this sandbox is completely different from any sandbox I know, let’s say windows sandboxed apps are running in a special container and also by applying some mitigation to their tokens (such as: lowering token integrity, applying the create process mitigation…) and other sandboxes actually run a suspicious file in a virtual machine instead so the file will stay completely isolated. But Avast sandbox is something completely different, the sandboxed app run in the OS and with few security mitigation to the sandboxed app token, such as removing some privileges like SeDebugPrivilege, SeShutdownPrivilege… while the token integrity stay the same, while this isn’t enough to make a sandbox. Avast sandbox actually create a virtualized file stream and registry hive almostly identical to the real one, while it also force the sandboxed app to use the virtualized stream by hooking every single WINAPI call ! This sounds cool but also sound impossible, any incomplete hooking could result in sandbox escape.

Btw, the virtualized file stream is located in “C:\avast! sandbox”

So normally to make any escape I should read any available write-ups related to avast sandbox escape, and after some research it look like I found something: CVE-2016-4025 and another bug by google project zero.

Nettitude Labs covered a crafted DeviceIoControll call in order to escape from the virtualization, they noticed after using the “Save As” feature in notepad the actual saved file is outside the sandbox (in the real filesystem) and it look like it’s my way to get out

I selected their way by clicking on “Save As” and it don’t seems to be working because the patch has disabled the feature but instead of clicking on “Save As” I clicked in “Print”

By doing that it look like we got another pop-up so normally I clicked print with the default printer “Microsoft XPS Document Writer”

And yup we will have a “Save As” window after clicking on Print

So clicked on Save, I really didn’t expected anything to happen but guess what

The file was spawned outside the virtualized file stream. That’s clearly a sandbox escape.

How ? it seems look like an external process written the file while impersonating notepad’s access token. And luckily since CVE-2020-1337 I was focused on learning the Printer API by reading every single documentation provided by Microsoft, while in other side. James Forshaw published something related to a windows sandbox escape by using the Printer API here.

So I assume we can easily escape from the sandbox if we managed to call the Printer API correctly, so we will begin with OpenPrinter function

And of course we will specify in pPrinterName the default printer that exist on a standard windows installation “Microsoft XPS Document Writer”

Next we will go for StartDocPrinter function which allow us to prepare a document for printing and the third argument looks kinda important

So we will take a look in DOC_INFO_1 struct and there’s some good news

Then the final result will look like this

Note: The bug was reported to the vendor but they didn’t replied as usual

a.   Privilege Escalation

It was a bit hard to find a privilege escalation but after taking some time, here you go Avast, there’s a feature in Avast called “REPAIR APP” after clicking on it, it look like a new child process is being created by Avast Antivirus Engine called “Instup.exe”

Probably there’s something worthy to look there, after attempting to repair the app. In this case we will be using a tool called Process Monitor

And as usual we got something that worth our attention, the instup process look for some non existing directories C:\stage0 and c:\stage1

So what if they exist ?

I created the c:\stage0 directory with a subfile inside it and I took a look on how the instup.exe behave against it and I observed an unexpected behaviour, instead of just deleting or ignoring the file it actually create a hardlink to the file

we can exploit the issue but the issue is that the hardlink have a random name and guessing it at the time of the hardlink we can redirect the creation to an arbitrary location but unluckily the hardlink random name is incredible hard to guess, if we attempted who know how much time it will take so I prefer to not look there instead I started looking somewhere else

In the end of the process of hardlink creation, you can see that both of them has been marked for deletion, probably we can abuse the issue to achieve an arbitrary file deletion bug.

I’ve created an exploit for the issue, the exploit will create a file inside c:\stage0 and will continuously look for the hardlink. When the hardlink is created the poc OpLock it until instup attempt to delete it, then the poc will move the file away and set c:\stage0 into junction to “\RPC CONTROL\” which there we will create a symbolic link to redirect the file deletion to an arbitrary file

Note: This bug wasn’t reported to the vendor.

PoC can be found here

McAfee Total Security

a.   Privilege Escalation

I already found bugs on this AV before and got acknowledged by vendor

For CVE-2020-7279 and CVE-2020-7282

CVE-2020-7282 was for an arbitrary file deletion issue in McAfee total protection and CVE-2020-7279 was for self-defence bypass.

The McAfee total security was vulnerable to an arbitrary file deletion, by creating a junction from C:\ProgramData\McAfee\Update to an arbitrary location result in arbitrary file deletion, the security patch was done by enforcing how McAfee total security updater handle reparse point.

But the most important is C:\ProgramData\McAfee\Update is actually protected by the self defence driver, so even an administrator couldn’t create files in this directory. The bypass was done by open the directory for GENERIC_WRITE access and then creating a mount point to the target directory so as soon the updater start it will delete the target directory subcontent.

But now a lot has changed, the directory now has subcontent (previously it was empty by default), 

After doing some analysis on how they fixed the self defence bug. Instead of preventing the directory opening (as it was expected) with GENERIC_WRITE they blocked the following control codes FSCTL_SET_REPARSE_POINT and FSCTL_SET_REPARSE_POINT_EX from being called on a protected filesystem component, I expected FSCTL_SET_REPARSE_POINT_EX but no they did a smart move in this case, so if we didn’t bypass the self defence we don’t have any actual impact on the component.

So this is it, this is as far as I can go… or no ?

a.   Novel way to bypass the self defence

This method work for all antiviruses which the filesystem filter.

So how does the kernel filter work ?

The filesystem filter restrict the access to the antivirus owned objects, by intercepting the user mode file I/O request, if the request coming from an antivirus component it will be granted, if not it will return access denied.

You can read more about that here, I already wrote some of them but for some private usage so for the moment I can’t disclose them, but there’s a bunch of examples you can find by example: here

So as far as I know there’s 2 way to bypass the filter

1.     Do a special call so it will be conflicted by what the driver see

2.     Request access from a protected component

So the special way was patched in CVE-2020-7279, the option that remain is the second one. How can we do that ?

The majority of the AV’s GUI support file dialog to select something let’s take by example McAfee file shredder which open a file dialog in order to let you choose to pick something

After running the code

It look like that the job is being done from the process not from an external process (such as explorer), so technically anything we do is considered to be done as the process.

Hold on, if the things are done by the process. Doesn’t that mean that we can create a folder in a protected location ? Yes we can

c.   Weaponizing the self-protection bypass

The CVE-2020-7282 patch was a simple check against reparse points, before managing to delete any directory.

There’s a simple check to be done, if FSCTL_GET_REPARSE_POINT control on a directory return anything except STATUS_NOT_A_REPARSE_POINT the target will removed else the updater will delete the subcontent as

“NT AUTHORITY\SYSTEM”

Chaining it together, I’ve an exploit which demonstrate the bug, first a directory in C:\updmgr will be created and then you should manually move it to C:\ProgramData\McAfee\Update an opportunistic lock will trigger the poc to create a reparse point to the target as soon as the AV GUI attempt to move the folder, the poc will set it to reparse point and will lock the moved directory so it will prevent the reparse point deletion.

PoC can be found here

    Avira Antivirus

Anyway it look like there’s a feature come with Avira Prime called Avira System Speedup Pro, I can’t still explain why this behaviour exist in Avira System Speedup feature but yeah it exist.

When starting the Avira System Speedup Pro GUI there’s an initialization done by the service “Avira.SystemSpeedup.Service.exe” which is written in C# which make it easier to reverse the service but I reversed the service and things just doesn’t make any sense so I guess it’s better to show process monitor output to understand the issue.

without even checking for reparse point. It’s extremely easy to abuse the issue.

This time instead of writing a c++ PoC I’ll be writing a simpler one as a batch script. The PoC in this case doesn’t need any user interaction, and will delete the targeted directory subcontent.

PoC can be found here

1    Trend Micro Maximum security

I already discovered an issue in trend micro and it was patched in CVE-2020-25775, I literally just found a high severity issue on trend micro. But I was contracted for so I can’t disclose it here.

Moving out, as other AV’s there’s a PC Health Checkup feature, it probably worth our attention.

While browsing trough the component, I noticed that there’s a feature “Clean Privacy Data” feature.

And as you see Trend Micro Platinum Host Service is deleting a directory in a user write-able location without proper check against reparse point while running as “NT AUTHORITY\SYSTEM” which is easily abuse-able by a user to delete arbitrary files.

There’s nothing to say more, I created a proof of concept as a batch script after running it expect the target directory subcontent to be deleted.

PoC can be found here

MalwareBytes

 

Yup, another good AV, Already engaged with the antivirus and as usual I got a bug. 5 months has passed since I reported the bug, they still didn’t patched the issue and since they paid the bounty, I can’t disclose the bug but as usual PAPA has candies for you !

I will using the same technique explained above to bypass the self protection.

While checking for updates, the antivirus look for a non existing directory

   Hmmmm, let’s take a look

The pic shown above, show us that Malwarebytes antivirus engine is deleting every subcontent of C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate\test.txt.txt and since there’s no impersonation of the user and literally no proper check against reparse point we can probably abuse that, by creating a directory there and creating a reparse point inside  C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate we can redirect the file deletion to an arbitrary location.

The PoC can be found here

1    Kaspersky

The AV which I engaged with the most, about 11 bugs were reported and 3 of them were fixed.

For the moment I will be talking about a bug which I already disclosed here, this PoC will spawn a SYSTEM shell as soon as it succeed, the bug seems to be still existing on Kaspersky Total Security with December 2020 latest security patches, the only issue you will have is the AV will detect the exploit as a malware, you must do some modification to prevent your exploit from being deleting. Let’s I can confirm that the issue still exist.

One more thing

Another issue I discovered in all Kaspersky’s antiviruses which allow arbitrary file overwrite without user interaction. I’ve already reported the bug to Kaspersky but they didn’t gave me a bug bounty

They said that the issue isn’t eligible for bug bounty because the reproduction of the issue is unstable, ain’t gonna lie I gave them a horrible proof of concept but still do the job so I guess it should be rewarded and since they wrote that they gave bounties. I won’t give bugs for free like a foo.

So let’s dive inside the bug, when any user start Mozilla Firefox, Kaspersky write a special in %Firefox_Dir%\defaults\pref while not impersonating the user or not even doing proper links check, if abused correctly it can be used against the AV to trigger arbitrary file overwrite on-demand without user interaction.

A proof of concept is attached implement the issue, I’ve rewritten a new one which will trigger your needs on demand thanks me later.

PoC can be found here

Windows

 

I was about to disclose bugs in Eset and Bitdefender but I don’t have time to write more, so here’s the last one.

First, if you’re not familiar with windows installer CVE-2020-16902, it’s literally the 6^th time I am bypassing the security patch and they still don’t hire security researchers. I will be using the same package as CVE-2020-16902

Microsoft has patched the issues by checking if c:\config.msi exist, if not it will be used to generate rollback directory otherwise if it exist c:\windows\installer\config.msi will be used as a folder to generate rollback files.

A tweet by sandboxescaper mentioned that if a registry key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi” existed when the installation begin, the windows installer will use c:\config.msi as a directory rollback files. As an unprivileged user I guess there’s no way to prevent the deletion or create “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi”

And as usual there’s always something that worth our attention.

When the directory is deleted, there’s an additional check if the directory exist or not. Which is kinda strange, since the RemoveDirectory returned TRUE

I guess there’s no need to make additional checks. I am pretty sure that there’s a bug there, I managed to create the directory as soon the installer delete and this happened

The installer did a check if the directory exist and it return that the directory exist, so the windows installer won’t delete the registry key  “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi” because the directory wasn’t delete.

In the next installation the C:\Config.Msi will be used to save rollback files on it, which can be easily abused (I’ve already done that in CVE-2020-1302 and CVE-2020-16902).

I’ve provided a PoC as c++ project to exploit the issue, it’s a double click to SYSTEM shell, thank me later again.

PoC can be found here

Dark HunTOR: Police corps across the world have arrested 150 individuals suspected of buying or selling illicit goods on the dark web marketplace DarkMarket.

A joint international operation, tracked as Dark HunTOR, conducted by law enforcement across the world resulted in the arrest of 150 suspects allegedly involved in selling and buying illicit goods in DarkMarket marketplace.

The authorities arrested 65 suspects in the United States, 47 in Germany, 24 in the United Kingdom, 4 in Italy, 4 in the Netherlands, 3 in France, 2 in Switzerland, and one in Bulgaria.

DarkMarket, the world’s largest black marketplace on the dark web, has been taken offline in January as a result of an international operation conducted by law enforcement from Germany, Australia, Denmark, Moldova, Ukraine, the United Kingdom (the National Crime Agency), and the USA (DEA, FBI, and IRS) with the support of the Europol.ⓘ

The figures related to the DarkMarket at the time of the shut down were impressive:

• almost 500 000 users;
• more than 2 400 sellers; 
• over 320 000 transactions;
• more than 4 650 bitcoin and 12 800 Monero transferred. 

The overall transactions, at the current rate, corresponding to a sum of more than €140 million.

The marketplace was an important point of aggregation for online cybercriminals that traded all kinds of drugs, counterfeit money, stolen or counterfeit credit card details, anonymous SIM cards and malware.

The authorities seized more than €26.7 million (USD 31 million) in cash and virtual currencies, as well as 234 kg of drugs and 45 firearms. The police seized 152 kg of amphetamine, 27 kg of opioids and over 25 000 ecstasy pills. 

“Operation Dark HunTOR stems from the takedown earlier this year of DarkMarket, the world’s then-largest illegal marketplace on the dark web. At the time, German authorities arrested the marketplace’s alleged operator and seized the criminal infrastructure, providing investigators across the world with a trove of evidence. Europol’s European Cybercrime Centre (EC3) has since been compiling intelligence packages to identify the key targets.” states the press release published by the Europol. “As a result, 150 vendors and buyers who engaged in tens of thousands of sales of illicit goods were arrested across Europe and the United States. A number of these suspects were considered as High-Value Targets by Europol.”

Europol says that the Dark HunTOR investigation is still ongoing.

The Italian police also shut down the DeepSea and Berlusconi dark web marketplaces as part of the Dark HunTOR operation. According to the press release, the two marketplaces had over 100 000 announcements of illegal products. The authorities arrested four administrators and seized €3.6 million in cryptocurrencies. 

“The point of operations such as the one today is to put criminals operating on the dark web on notice: the law enforcement community has the means and global partnerships to unmask them and hold them accountable for their illegal activities, even in areas of the dark web,” said Jean-Philippe Lecouffe, Europol’s Deputy Executive Director of Operations.

“The FBI continues to identify and bring to justice drug dealers who believe they can hide their illegal activity through the Darknet,” said FBI Director Christopher A. Wray. “Criminal darknet markets exist so drug dealers can profit at the expense of others’ safety. The FBI is committed to working with our JCODE and EUROPOL law enforcement partners to disrupt those markets and the borderless, worldwide trade in illicit drugs they enable.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, cybercrime)

This webapp is a browser and desktop password manager compatible with KeePass databases. It doesn't require any server or additional resources. The app can run either in browser, or as a desktop app.

Apps: Web, Desktop
Timeline: Release Notes, TODO
On one page: Features, FAQ
Website: keeweb.info
Twitter: kee_web
Donate: OpenCollective, GitHub

The app is quite stable now. Basic stuff, as well as more advanced operations, should be rather reliable.

Everything you need to host this app on your server is any static file server. The app is a single HTML file + a service worker (optionally; for offline access). You can download the latest distribution files from gh-pages branch.

If you are using Docker:

1. put your dh.pem, cert.pem, key.pem to /etc/nginx/external/
2. run this script:

docker run --name keeweb -d -p 443:443 -p 80:80 -v $EXT_DIR:/etc/nginx/external/ antelle/keeweb

To make Dropbox work in your self-hosted app, go to this Wiki page.

The easiest way to clone all KeeWeb repos is:

curl https://raw.githubusercontent.com/keeweb/keeweb/develop/dev-env.sh | bash -

The app can be built with grunt: grunt (html files will be in dist/).
Desktop apps are built with grunt desktop. This requires some magic and currently works only on CI, you can find more details in the GitHub Actions workflow.

To run the desktop (electron) app without building an installer, build the app with grunt and start it this way:

npm run dev
npm run electron

For debug build:

1. run npm run dev
2. open http://localhost:8085

To build desktop apps, use these goals, the result can be found in tmp:

npm run dev-desktop-macos
npm run dev-desktop-windows
npm run dev-desktop-linux

Please read contribution guidelines for pull requests.
Here's a list of issues where your help would be very welcome. Also you can help by translating KeeWeb to your language.

Other ways of contribution can be found on this page.

• please branch from develop, not master
• don't edit translation files except base.json, they will be replaced

KeeWeb is not free to develop. It takes time, requires paid code signing certificates and domains.
You can help the project or say "thank you" with this button:

You can also sponsor the developer directly on GitHub.

Please note: donation does not imply any type of service contract.

Notable contributions to KeeWeb:

• Florian Reuschel (@Loilo): German translation
• Dennis Ploeger (@dploeger): auto-type improvements
• Hackmanit (hackmanit.de): penetration test
• Peter Bittner (@bittner): Wikipedia article

A researcher from the security firm CyberArk has managed to crack 70% of Tel Aviv’s Wifi Networks starting from a sample of 5,000 gathered WiFi.

CyberArk security researcher Ido Hoorvitch demonstrated how it is possible to crack WiFi at scale by exploiting a vulnerability that allows retrieving a PMKID hash.

Hoorvitch has managed to crack 70% of a 5,000 WiFi network sample in Tel Aviv to demonstrate that it is easy to compromise WiFi networks.CyberArk security researcher Ido Hoorvitch first wandered in the city center with WiFi sniffing equipment to gather a sample of 5,000 network hashes to use in the research.

The expert gathered 5,000 WiFi network hashes by strolling the streets in Tel Aviv with simple WiFi sniffing equipment composed of an AWUS036ACH ALFA Network card ($50) that can work in monitoring mode and is able to inject packets.

The expert used the free and open-source packet analyzer.WireShark running on Ubuntu.

The PMKID is calculated by using a hashing function having the PMK, the PMK Name, the MAC_AP and the MAC_STA as input.

The PMK is calculated from the following parameters:

• Passphrase– The WiFi password — hence, the part that we are really looking for.
• SSID – The name of the network. It is freely available at the router beacons (Figure 3).
• 4096 – Static integer for all PMK

Hoorvitch used an attack technique devised by Jens “atom” Steube’s (Hashcat’s lead developer) to retrieve the PMKIDs that allowed him to derive the password.

“All of this changed with the atom’s groundbreaking research, which exposed a new vulnerability targeting RSN IE (Robust Security Network Information Element) to retrieve a PMKID hash (will be explained in a bit) that can be used to crack the target network password. PMKID is a hash that is used for roaming capabilities between APs. The legitimate use of PMKID is, however, of little relevance for the scope of this blog. Frankly, it makes little sense to enable it on routers for personal/private use (WPA2-personal), as usually there is no need for roaming in a personal network.” reads the post published by Hoorvitch.

The attack technique is clientless, this means that an attacker doesn’t need to carry out the attack in real-time, he just needs to capture a single frame and eliminate wrong passwords and malformed frames that are disturbing the cracking process.

The expert first used “mask attack” as a Hashcat cracking method, he used a combination of dictionary + rules and mask attack because many Israeli citizens have the bad habit of using their cellphone numbers as WiFi passwords. 

Israeli phone numbers have 10 digits and starts with 05, so it’s only eight digits, this means that remained only 8 digits to guess. Using a standard laptop, Hoorvitch successfully cracked 2,200 passwords at an average speed of nine minutes per password.

“Each digit has 10 options (0-9), hence 10**8 possible combinations. One hundred million seems like a lot of combinations, but our monster rig calculates at the speed of 6819.8 kH/s which translates into 6,819,000 hashes per second.” continues the post. “A cracking rig is not required as my laptop can get to 194.4 kH/s, which translates into 194,000 hashes per second. That equals more than enough computing power to cycle through the possibilities necessary to crack the passwords. Consequently, it took my laptop roughly 9 minutes to break a single WiFi password with the characteristics of a cellphone number. (10**8)/194,000 = ~516 (seconds)/60 = ~9 minutes.”

In a second phase, the expert used a standard dictionary attack technique leveraging the ‘Rockyou.txt’ dictionary.

He cracked another 1,359 passwords using this technique, most of cracked passwords contain only digits or only lower-case characters.

The expert pointed out that only routers supporting roaming features are vulnerable to the PMKID attack, however, the research demonstrated that routers manufactured by major vendors are vulnerable.

“In total, we cracked more than 3,500 WiFi network in and around Tel Aviv – 70% of our sample.” concludes the expert. “The threat of a compromised WiFi network presents serious risk to individuals, small business owners and enterprises alike. And as we’ve shown, when an attacker can crack more than 70% of WiFi networks in a major global city with relative ease, greater attention must be paid to protecting oneself.”

Below are the recommendations provided by the expert to protect themselves:

1. Choose a complex password. A strong password should include at least one lower case character, one upper case character, one symbol, one digit. It should be at least 10 characters long. It should be easily remembered and hard to anticipate. Bad example: Summer$021
2. Change the default username and password of your router.
3. Update your router firmware version.
4. Disable weak encryption protocols (as WAP or WAP1).
5. Disable WPS.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, WiFi)

U.S. federal investigators today raided the Florida offices of PAX Technology, a Chinese provider of point-of-sale devices used by millions of businesses and retailers globally. KrebsOnSecurity has learned the raid is tied to reports that PAX’s systems may have been involved in cyberattacks on U.S. and E.U. organizations.

FBI agents entering PAX Technology offices in Jacksonville today. Source: WOKV.com.

Headquartered in Shenzhen, China, PAX Technology Inc. has more than 60 million point-of-sale terminals in use throughout 120 countries. Earlier today, Jacksonville, Fla. based WOKV.com reported that agents with the FBI and Department of Homeland Security (DHS) had raided a local PAX Technology warehouse.

In an official statement, investigators told WOKV only that they were executing a court-authorized search at the warehouse as a part of a federal investigation, and that the inquiry included the Department of Customs and Border Protection and the Naval Criminal Investigative Services (NCIS). The FBI has not responded to requests for comment.

Several days ago, KrebsOnSecurity heard from a trusted source that the FBI began investigating PAX after a major U.S. payment processor started asking questions about unusual network packets originating from the company’s payment terminals.

According to that source, the payment processor found that the PAX terminals were being used both as a malware “dropper” — a repository for malicious files — and as “command-and-control” locations for staging attacks and collecting information.

“FBI and MI5 are conducting an intensive investigation into PAX,” the source said. “A major US payment processor began asking questions about network packets originating from PAX terminals and were not given any good answers.”

KrebsOnSecurity reached out to PAX Technology’s CEO on Sunday. The company has not yet responded to requests for comment.

The source said two major financial providers — one in the United States and one in the United Kingdom — had already begun pulling PAX terminals from their payment infrastructure, a claim that was verified by two different sources.

“My sources say that there is tech proof of the way that the terminals were used in attack ops,” the source said. “The packet sizes don’t match the payment data they should be sending, nor does it correlate with telemetry these devices might display if they were updating their software. PAX is now claiming that the investigation is racially and politically motivated.”

The source was unable to share specific details about the strange network activity that prompted the FBI’s investigation. But it should be noted that point-of-sale terminals and the technology that supports them are perennial targets of cybercriminals.

It is not uncommon for payment terminals to be compromised remotely by malicious software and made to collect and transmit stolen information. Indeed, some of history’s largest cyberheists involved point-of-sale malware, including the 2008 breach at Heartland Payment Systems that exposed 100 million payment cards, and the 2013-2014 string of breaches at Target, Home Depot and elsewhere that led to the theft of roughly another 100 million cards.

Even if it were publicly proven today that the company’s technology was in fact a security risk, my guess is few retailers would be quick to do much about it in the short run. The investigation into PAX Technology comes at a dicey time for retailers, many of whom are gearing up for the busy holiday shopping season. What’s more, global computer chip shortages are causing lengthy delays in procuring new electronics.

Third Party Risk Management (“TPRM”) efforts are often considered labour-intensive, with numerous tedious, manual steps. Often, an equal amount of effort is put into managing the process as is to focusing on risks. In order to avoid this, we’d like to share three ways in which we’ve been boosting our own TPRM efficiency – through automation of three crucial phases in the third party risk assessment process:

(1) during initiation (the business risk/criticality assessment),

(2) while performing your third party (due diligence) assessments and

(3) during the monitoring phase following the assessment.

This article elaborates further on the automation of the above.

1. Automate the third-party criticality assessment

When you are applying a risk-based approach to your TPRM efforts, third party assessments are initiated with a criticality or business risk assessment using information from the business owner working with the third party. Most of our customers will document the criticality assessment in an Excel file with a lot of back-and-forth communication.

When reviewing the intake form, we realised that the intake could be distilled to a few multiple-choice questions, such as the highest category of data the third-party can access, the level of system access and so on. We created the possibility for the customer to conduct a short, simplified assessment through Microsoft Forms. This is easily available through one single link and avoids clutter (caused by different versions of Excel files, for example). In addition, through Microsoft Flow, the output from that Form is automatically grabbed and imported in a repository. Finally, we made sure an MS Planner Task is created for each new assessment which triggers the involvement of the security second line function.

This approach results in significant value increase because it can:

• Give the business owner a more user-friendly GUI rather than an Excel sheet, which they are expected to complete.
• Enable owners to initiate a third-party security assessment at any given time, without the initiation by second line.
• Empower the second line to focus on understanding and challenging the provided input.
• Improve administration aspects around the execution of the third-party security risk assessments are completed within a short time frame.

Do you want to take it to the next level? Integrate an automated approval through Power Automate for the security team.

The above case requires a low effort customisation to fully tailor this to your organisation and guarantees time efficiencies and better flexibility.

2. Automate the execution of the assessments by leveraging tooling

You might still be wondering: how do we finally get rid of those Excel files to exchange with our third parties?  You could address this by using tooling throughout the assessment process. By leveraging these tools (such as Ceeyu, OneTrust Vendorpedia, Security Scorecard Atlas, Qualys SAQ, Prevalent and more) not only the tedious tasks of the criticality assessment, but also those of the consequential third party due diligence assessment, can be automated. Examples of tasks we have automated with such tooling include:

• The exchange of the due diligence questionnaires.
• The uploading and collecting of supporting evidence.
• The tracking of the overall progress of the assessment (including the history of the review), and
• Reporting of the assessment outcome and scoring (including comparison of vendors).

Again, significant value increase is the result and you can:

• Reduce time-to-market: the administrative overhead per assessment, leading to a reduced average lead time of the assessment.
• Identify bottlenecks: clearly pinpoint the bottleneck if the assessment does get stuck somewhere with a centralized overview of the actual status of the assessment.
• Free up valuable time: allow the security team reviewing the provided input to focus their time on what really matters: reviewing the output.
• Leverage reporting possibilities: minimise the effort in creating custom reports for management reporting using the cutting edge built-in reporting features.

Of course, this requires having the right tools at your disposition – however, implemented at scale, the efficiency and quality returns of the tools nearly always surpass the cost of such tooling. At NVISO for example, we’ve been able to decrease our nominal assessment cost by about 20% and our tool provides a portal to our customers that brings transparency and visibility on the handling of incoming TPRM requests.

3. Automate the monitoring and follow-up on agreed actions by leveraging tooling

In order to maximise automation, you should also consider it for your monitoring actions. Very often assessments remain a point-in-time assessment (“snapshot”) which only paints a partial picture on how seriously your third parties take security. It is of equal importance to monitor their efforts to improve their security posture over time – i.e. the timely and effective implementation of your recommendations, and the evolution of their overall security posture. Automation can also play a major role in this process.

Here also, you would create value increase because you can:

• Automate action plan monitoring: send automated reminders to the third parties in line with set due dates for identified follow-up actions.
• Automate escalation: escalate to the business owner in case of overdue actions, potentially with different business rules depending on the business criticality of the supplier.
• Free up valuable time: reducing manual interventions of your second line team helps focusing on where it really matters: is the identified action effectively addressed? Is the remediation effective in reducing the risk? We typically adopt a risk-driven, sample-based approach in verifying this.
• Stay up to date: trigger automated reinitiation of assessments when they are due for a third party.

To facilitate this, you will again require the right tools at your disposition. A dedicated TPRM tool is a plus, although it’s perfectly feasible to also realise this through Microsoft 365 for example. This monitoring process is also something we offer as an option in our TPRM as a service solution.

Conclusion

To summarise: all of the above automation efforts (even through leveraging tools you might already have at hand) can significantly increase the value you get from your efforts in the Third Party Risk Management (TPRM) process. Customers, as well as third parties, see the benefits of these automation initiatives in the process: it reduces their involvement, it’s easier to track the various assessments and eventually it allows them to focus on the outcome of their TPRM efforts.

If you are looking at ways to boost your TPRM efforts and are seeking assistance in implementing this within your organisation, don’t hesitate to reach out to me through [email protected].

The FBI published a flash alert to warn of the activity of the Ranzy Locker ransomware that had already compromised tens of US companies.

The FBI published a flash alert to warn of Ranzy Locker ransomware operations that had already compromised at least 30 US companies this year.

The gang has been active since at least 2020, threat actors hit organizations from various industries.

“Unknown cyber criminals using Ranzy Locker ransomware had compromised more than 30 US businesses as of July 2021. The victims include the construction subsector of the critical manufacturing sector, the academia subsector of the government facilities sector, the information technology sector, and the transportation sector.” reads the flash alert.

The attack vector most used by the Ranzy Locker ransomware operators are brute force attempts targeting Remote
Desktop Protocol (RDP) credentials. In recent attacks, the group also exploited known Microsoft Exchange Server vulnerabilities and used phishing messages to target computer networks.

Once gained access to the target network, the ransomware gang attempts to locate sensitive data, including customer information, PII related files, and financial records. The Ranzy Locker ransomware targets Windows systems, including servers and virtual machines.

In some cases the group implemented a double model of extortion, threatening victims to leak the stolen data if they don’t pay the ransom.

The flash alert also includes indicators of compromise (IOCs) associated with Ranzy Locker operations and Yara rules to detect the threat.

Below are the recommended mitigations included in the alert:

• Implement regular backups of all data to be stored as air gapped, password protected copies offline. Ensure these copies are not accessible for modification or deletion from any system where the original data resides.
• Implement network segmentation, such that all machines on your network are not accessible from every other machine.
• Install and regularly update antivirus software on all hosts, and enable real time detection.
• Install updates/patch operating systems, software, and firmware as soon as updates/patches are released.
• Review domain controllers, servers, workstations, and active directories for new or unrecognized user accounts.
• Audit user accounts with administrative privileges and configure access controls with least privilege in mind. Do not give all users administrative privileges.
• Disable unused remote access/Remote Desktop Protocol (RDP) ports and monitor remote access/RDP logs for any unusual activity.
• Consider adding an email banner to emails received from outside your organization.
• Disable hyperlinks in received emails.
• Use double authentication when logging into accounts or services.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Ranzy Locker ransomware)