Daily Archives: November 9, 2020

Use Caution Opening Email Attachments

A common method cyber criminals use to hack into people's computers is to send them emails with infected attachments. People are tricked into opening these attachments because they appear to come from someone or something they know and trust. Only open email attachments that you were expecting. Not sure about an email? Call the person to confirm they sent it.

What is Policy Compliance? Four Tips to Help You Succeed

Policy compliance within the information security space can be an exhausting concept to wrap our heads around. Writing a policy document, publishing it to staff and then staying hands-on to ensure it is followed in perpetuity is easily seen as an arduous, if not an impossible, task. Policies set the basis for every successful information […]… Read More

The post What is Policy Compliance? Four Tips to Help You Succeed appeared first on The State of Security.

Canadian CEO surprised how little federal government buys from Canadian cybersecurity sector

Federal study of cybersecurity sector shows Ottawa acccounted for only eight per cent of sales in 2018. An industry association would like it to be 50 per cent

The post Canadian CEO surprised how little federal government buys from Canadian cybersecurity sector first appeared on IT World Canada.

What You Need to Know About Among Us

Among Us – one of the Most Popular Online Game of 2020

(pictured credit: axel 795, Pixabay)

If you have teens and you haven’t yet heard of ‘Among Us’ then I guarantee it won’t be long. Among Us is an online deception and strategy game that is having a real moment worldwide. Over the last six months, it has amassed 85 million players on both PC and mobile. In September, it broke the all-time record-setting peak player ceiling on Steam when nearly 400,000 people played it simultaneously and, Google Trends reports that there were 50 times more Google searches for it at the beginning of October, as compared to the beginning of August.

What’s The Game About?

Among Us is an online multi-player game that is set on a failing spaceship. Suitable for up to 10 players, it has been compared to ‘Murder in the Dark’ or ‘Murder Wink’ – the old-school party game you may have played as children.

At the start of the game, you’re advised whether you are a regular crew member or an imposter. Crew mates are tasked with completing small tasks that benefit the spaceship eg cleaning our air-conditioning ducts whereas imposters (between 1-3 players) create havoc on the spaceship and seek out victims to kill – without letting anyone know.

Every time a dead body is found, a crewmember will call a meeting to workshop who they think the imposter is. This is one of the few times players can talk to each other. As you can imagine, this can get very heated (and entertaining) as players try to implicate others and remove themselves from focus. All players then vote on who they think the imposter is – and the player with the most votes is ejected from the spaceship’s airlock.

Crewmates win by managing to repair the ship and eject all the imposters while the imposter wins by killing all the crewmates before they complete their jobs.

Why Has It Become So Popular?

Among Us was actually launched in 2018 but to little fanfare. But the planets have aligned for the developers at InnerSloth and it has become one of the biggest online games ever. In fact, it’s so successful that the developers have abandoned plans for a sequel and are instead, investing their resources into perfecting the original.

There’s no doubt that pandemic life has contributed to the popularity of Among Us with many touting it as the ultimate group party game. In fact, some believe it brings all the energy and pizazz of board game night – just virtually.

It is extremely easy to learn. So, if you aren’t a gamer with years of experience (that’s me) you can absolutely play. This concept has been described by popular YouTube gamer Pegasus as ‘ingenious’ for its simplicity, and praised for its ‘extremely social’ nature.

The game is also very well priced. In fact, it’s free on mobile – but you will have to view some ads. And it’s only around $7 on a PC – so much cheaper than anything my kids have played in years!

What Parents Are Asking

Is it Suitable?

The Classification Board here is Australia gives Among Us a PG rating which means the content is mild in impact. But they do state that PG rated content is ‘not recommended for viewing by people under the age of 15 without guidance from parents, teachers or guardians.’

In Australia, the game is rated as suitable for 9+ on the App Store. On Google Play it is nominated as suitable for ages 10+.

The role of the imposter in the game to hunt and murder players is aggressive and violent. Yes, it is a cartoon-like visual which does reduce the impact but there are still bodies left lying around after the deed is done.

Parents know their children the best. Absolutely take heed of the advice, but ultimately, you need to decide what’s suitable for them. If you do decide to let your younger children play – or they’ve already discovered it – please talk about violence in video games. Does watching violent images make them feel scared or more aggressive? Do they feel better if they talk about it or, in fact, choose to watch something less violent?

Can They Chat With Strangers During The Game?

There is opportunity to chat with strangers in the game but it is less than most online games. Players can chat in the online waiting room before a game starts and of course, there is also interaction in the meetings during which the group tries to work out who the imposter is. Enabling the censor chat mode is a good option here – this limits word and aims to block out expletives however I understand that isn’t completely fool proof.

But you can choose to play the game offline, locally, which means you play only with people you know. You simply share a generated code with the players you want to join the game. I highly recommend this for younger children and teens or if you want to play the game as a family. The game can be played with as few as four players which makes an offline game far easier to get happening.

Does It Share A Positive Message?

Both trust and deceit are at the core of this game. Learning who to place your trust in is part of being a successful crewmember in Among Us whilst being a master of deceit will win you the game as an imposter.

You could argue that these themes are no different to playing Murder in the Dark or even the old classic Cluedo. However, I would absolutely have a conversation with your kids about the difference between real life and online (or gaming) life. Why not weave it into your dinnertime conversation?

My boys are really enjoying playing Among Us, in fact – we have earmarked this weekend for a family game. But please ensure you are comfortable with the game before you give your kids the green light. And if you do, be assured that one of the reasons this game is so popular is because players feel like they are part of a community – and isn’t that what we all need at the moment?

‘till next time.

Alex xx

The post What You Need to Know About Among Us appeared first on McAfee Blogs.

Millions of hotel guests worldwide have their private details exposed

A sloppy lack of security by a hotel reservation platform has left highly sensitive information about millions of people worldwide exposed. Security experts uncovered a misconfigured AWS S3 bucket containing over 10 million files, containing information about hotel guests dating as far back as 2013.

WOW64!Hooks: WOW64 Subsystem Internals and Hooking Techniques

Microsoft is known for their backwards compatibility. When they rolled out the 64-bit variant of Windows years ago they needed to provide compatibility with existing 32-bit applications. In order to provide seamless execution regardless of application bitness, the WoW (Windows on Windows) system was coined. This layer, which will be referred to as ‘WOW64’ from here on out, is responsible for translating all Windows API calls from 32-bit userspace to the 64-bit operating system kernel. This blog post is broken up into two sections. First we start by diving deep into the WOW64 system. To do this, we trace a call from 32-bit userspace and follow the steps it takes to finally transition to the kernel. The second part of the post assesses two hooking techniques and their effectiveness. I will cover how this system works, the ways malware abuses it, and detail a mechanism by which all WoW syscalls can be hooked from userspace. Note that all information here is true as of Windows 10, version 2004 and in some cases has changed from how previous Windows versions were implemented.


First and foremost, this is a topic which has existing research by multiple authors. This work was critical in efficient exploration of the internals and research would have taken much longer had these authors not publicly posted their awesome work. I would like to callout the following references:

  • (wbenny): An extremely detailed view of WOW64 internals on ARM
  • (ReWolf): A PoC heaven’s gate implementation
  • (JustasMasiulis): A very clean C++ heaven’s gate implementation
  • (MalwareTech): A WOW64 segmentation explanation

WOW64 Internals

To understand how the WOW64 system works internally we will explore the call sequence starting in 32-bit usermode before transitioning into the kernel from within a system DLL. Within these system DLLs the operating system will check arguments and eventually transition to a stub known as a syscall stub. This syscall stub is responsible for servicing the API call in the kernel. On a 64-bit system, the syscall stub is straightforward as it directly executes the syscall instruction as shown in Figure 1.

Figure 1: Native x64 Syscall Stub

Figure 2 shows a syscall stub for a 32-bit process running on WOW64

Figure 2: WOW64 Syscall Stub

Notice that instead of a syscall instruction in the WOW64 version, Wow64SystemServiceCall is called. In the WOW64 system what would normally be an entry into the kernel is instead replaced by a call to a usermode routine. Following this Wow64SystemServiceCall, we can see in Figure 3 that it immediately performs an indirect jmp through a pointer named Wow64Transition.

Figure 3: Wow64SystemService transitions through a pointer ‘Wow64Transition’

Note that the Wow64SystemServiceCall function is found within ntdll labeled as ntdll_77550000; a WOW64 process has two ntdll modules loaded, a 32-bit one and a 64-bit one. WinDbg differentiates between these two by placing the address of the module after the 32-bit variant. The 64-bit ntdll can be found in %WINDIR%\System32 and the 32-bit in %WINDIR%\SysWOW64. In the PDBs, the 64bit and 32bit ntdlls are referred to as ntdll.pdb and wntdll.pdb respectively, try loading them in a disassembler! Continuing with the call trace, if we look at what the Wow64Transition pointer holds we can see its destination is wow64cpu!KiFastSystemCall. As an aside, note that the address of wow64cpu!KiFastSystemCall is held in the 32-bit TEB (Thread Environment Block) via member WOW32Reserved, this isn’t relevant for this trace but is useful to know. In Figure 4 we see the body of KiFastSystemCall.

Figure 4: KiFastSystemCall transitions to x64 mode via segment selector 0x33

The KiFastSystemCall performs a jmp using the 0x33 segment selector to a memory location just after the instruction. This 0x33 segment transitions the CPU into 64-bit mode via a GDT entry as described by (MalwareTech).

Let's recap the trace we've performed to this point. We started from a call in ntdll, NtResumeThread. This function calls the Wow64SystemServiceCall function which then executes the Wow64Transition. The KiFastSystemCall performs the transition from 32-bit to 64-bit execution. The flow is shown in Figure 5.

Figure 5: 32-bit to 64-bit transition

The destination of the CPU transition jump is the 64-bit code show in Figure 6.

Figure 6: Destination of KiFastSystemCall

Figure 6 shows the first 64-bit instruction we’ve seen executed in this call trace so far. In order to understand it, we need to look at how the WOW64 system initializes itself. For a detailed explanation of this refer to (wbenny). For now, we can look at the important parts in wow64cpu!RunSimulatedCode.

Figure 7: 64bit registers are saved in RunSimulatedCode

Figure 7 depicts the retrieval of the 64-bit TEB which is used to access Thread Local Storage at slot index 1. Then the moving of a function pointer table into register r15. The TLS data retrieved is an undocumented data structure WOW64_CPURESERVED that contains register data and CPU state information used by the WOW64 layer to set and restore registers across the 32-bit and 64-bit boundaries. Within this structure is the WOW64_CONTEXT structure, partially documented on the Microsoft website. I have listed both structures at the end of this post. We’ll look at how this context structure is used later, but for our understanding of the jmp earlier all we need to know is that r15 is a function pointer table.

It’s interesting to note at this point the architecture of the WOW64 layer. From the perspective of the 64-bit kernel the execution of 32-bit (Wow64) usermode applications is essentially a big while loop. The loop executes x86 instructions in the processor's 32-bit execution mode and occasionally exits the loop to service a system call. Because the kernel is 64-bit, the processor mode is temporarily switched to 64-bit, the system call serviced, then the mode switched back and the loop continued where it was paused. One could say the WOW64 layer acts like an emulator where the instructions are instead executed on the physical CPU.

Going back to the jmp instruction we saw in Figure 6, we now know what is occurring. The instruction jmp [r15 + 0xF8] is equivalent to the C code jmp TurboThunkDispatch[0xF8 / sizeof(uint64_t)]. Looking at the function pointer at this index we can see we’re at the function wow64cpu!CpupReturnFromSimulatedCode (Figure 8).

Figure 8: TurboThunk table's last function pointer entry is an exit routine

This routine is responsible for saving the state of the 32-bit registers into the WOW64_CONTEXT structure we mentioned before as well as retrieving the arguments for the syscall. There is some trickiness going on here, so let’s examine this in detail. First a pointer to the stack is moved into r14 via xchg, the value at this location will be the return address from the syscall stub where Wow64SystemServiceCall was called. The stack pointer r14 is then incremented by 4 to get a pointer to where the stack should be reset when it’s time to restore all these context values. These two values are then stored in the context’s EIP and ESP variables respectively. The r14 stack pointer is then incremented one more time to get the location where the __stdcall arguments are (remember stdcall passes all arguments on the stack). This argument array is important for later, remember it. The arguments pointer is moved into r11, so in C this means that r11 is equivalent to an array of stack slots where each slot is an argument uint32_t r11[argCount]. The rest of the registers and EFlags are then saved.

Once the 32-bit context is saved, the WOW64 layer then calculates the appropriate TurboThunk to invoke by grabbing the upper 16 bits of the syscall number and dispatches to that thunk. Note that at the beginning of this array is the function TurboDispatchJumpAddressEnd, shown in Figure 9, which is invoked for functions that do not support TurboThunks.

Figure 9: TurboThunk table's first function pointer entry is an entry routine

TurboThunks are described by (wbenny)—read his blog post at this point if you have not. To summarize the post, for functions that have simple arguments with widths <= sizeof(uint32_t) the WOW64 layer will directly widen these arguments to 64 bits via zero or sign-extension and then perform a direct syscall into the kernel. This all occurs within wow64cpu, rather than executing a more complex path detailed as follows. This acts as an optimization. For more complex functions that do not support TurboThunks the TurboDispatchJumpAddressEnd stub is used which dispatches to wow64!SystemServiceEx to perform the system call as shown in Figure 10.

Figure 10: Complex system calls go through Wow64SystemServiceEx

We’ll look at this routine in a moment as it’s the meat of this blog post, but for now let’s finish this call trace. Once Wow64SystemServiceEx returns from doing the system call the return value in eax is moved into the WOW64_CONTEXT structure and then the 32-bit register states are restored. There’s two paths for this, a common case and a case that appears to exist only to be used by NtContinue and other WOW64 internals. A flag at the start of the WOW64_CPURESERVED structure retrieved from the TLS slot is checked, and controls which restore path to follow as shown in Figure 11.

Figure 11: CPU state is restored once the system call is done; there’s a simple path and a complex one handling XMM registers

The simpler case will build a jmp that uses the segment selector 0x23 to transition back to 32-bit mode after restoring all the saved registers in the WOW64_CONTEXT. The more complex case will additionally restore some segments, xmm values, and the saved registers in the WOW64_CONTEXT structure and then will do an iret to transition back. The common case jmp once built is shown in Figure 12.

Figure 12: Dynamically built jmp to transition back to 32bit mode

At this point our call trace is complete. The WOW64 layer has transitioned back to 32-bit mode and will continue execution at the ret after Wow64SystemServiceCall in the syscall stub we started with. Now that an understanding of the flow of the WOW64 layer itself is understood, let’s examine the Wow64SystemServiceEx call we glossed over before.

A little bit into the Wow64SystemServiceEx routine, Figure 13 shows some interesting logic that we will use later.

Figure 13: Logging routines invoked before and after dispatching the syscalls

The routine starts by indexing into service tables which hold pointers to routines that convert the passed argument array into the wider 64-bit types expected by the regular 64-bit system modules. This argument array is exactly the stack slot that was stored earlier in r14.

Two calls to the LogService function exist, however these are only called if the DLL %WINDIR%\system32\wow64log.dll is loaded and has the exports Wow64LogInitialize, Wow64LogSystemService, Wow64LogMessageArgList, and Wow64LogTerminate. This DLL is not present on Windows by default, but it can be placed there with administrator privileges. 

The next section will detail how this logging DLL can be used to hook syscalls that transition through this wow64layer. Because the logging routine LogService is invoked before and after the syscall is serviced we can achieve a standard looking inline hook style callback function capable of inspecting arguments and return values.

Bypassing Inline Hooks

As described in this blog post, Windows provides a way for 32-bit applications to execute 64-bit syscalls on a 64-bit system using the WOW64 layer. However, the segmentation switch we noted earlier can be manually performed, and 64-bit shellcode can be written to setup a syscall. This technique is popularly called “Heaven’s Gate”. JustasMasiulis’ work call_function64 can be used as a reference to see how this may be done in practice (JustasMasiulis). When system calls are performed this way the 32-bit syscall stub that the WOW64 layer uses is completely skipped in the execution chain. This is unfortunate for security products or tracing tools because any inline hooks in-place on these stubs are also bypassed. Malware authors know this and utilize “Heaven’s Gate” as a bypass technique in some cases. Figure 14 and Figure 15 shows the execution flow of a regular syscall stub through the WOW64 layer, and hooked syscall stub where malware utilizes “Heaven’s Gate”.

Figure 14: NtResumeThread transitioning through the WOW64 layer

Figure 15: NtResumeThread inline hook before transitioning through the WOW64 layer

As seen in Figure 15, when using the Heaven’s Gate technique, execution begins after the inline hook and WOW64 layer is done. This is an effective bypass technique, but one that is easy to detect from a lower level such as a driver or hypervisor. The easiest bypass to inline hooks is simply to restore the original function bytes, usually from bytes on disk. Malware such as AgentTesla and Conti has been known to utilize this last evasion technique.

Hooking WOW64 via Inline Hooks

As a malware analyst being able to detect when samples attempt to bypass the WOW64 layer can be very useful. The obvious technique to detect this is to place inline hooks on the 64-bit syscall stubs as well as the 32-bit syscall stubs. If the 64-bit hook detects an invocation that didn’t also pass through the 32-bit hook, then it’s known that a sample is utilizing Heaven’s Gate. This technique can detect both evasion techniques previously detailed. However, in practice this is very difficult to implement. Looking at the requirements that must be satisfied to hook the 64-bit syscall stub we come up with this list:

  1. Install 64-bit hook from a 32-bit module
    • How do you read/write 64-bit address space from a 32-bit module?
  2. Implement a 64-bit callback from a 32-bit module
    • Typically, inline hooking uses C functions as callback stubs, but we’re compiling a 32-bit module so we’ll have a 32-bit callback instead of the required 64-bit one.

To solve the first challenge ntdll kindly provides the exports NtWow64ReadVirtualMemory64, NtWow64WriteVirtualMemory64, and NtWow64QueryInformationProcess64. Using these it is possible to read memory, write memory, and retrieve the PEB of a 64-bit module from a 32-bit process. However, the second challenge is much harder as either shellcode or a JIT will be required to craft a callback stub of the right bitness. In practice ASMJIT may be utilized for this. This is however a very tedious technique to trace a large number of APIs. There are other challenges to this technique as well. For example, in modern Windows 10 the base address of ntdll64 is set to a high 64-bit address rather than a lower 32-bit address as in Windows 7. Due to this, supporting returns from callbacks back up to the original hooked stub and allocating a trampoline within the required memory range is difficult since the standard ret instruction doesn’t have enough bits on the stack to represent the 64-bit return address.

As an aside, it should be noted that the WOW64 layer contains what is likely a bug when dealing with the NtWow64* functions. These APIs all take a HANDLE as first argument, which should be sign extended to 64-bits. However, this does not occur for these APIs, therefore when using the pseudo handle -1 the call fails with STATUS_INVALID_HANDLE. This bug was introduced in an unknown Windows 10 version. To successfully use these APIs OpenProcess must be used to retrieve a real, positive valued handle.

I will not be covering the internals of how to inline hook the 64-bit syscall stub since this post is already very long. Instead I will show how my hooking library PolyHook2 can be extended to support cross-architecture hooking using these Windows APIs, and leave the rest as an exercise to the reader. This works because PolyHook’s trampolines are not limited to +-2GB and do not spoil registers. The internals of how that is achieved is a topic for another post. Figure 16 depicts how to overload the C++ API of polyhook to read/write memory using the aforementioned WinAPIs.

Figure 16: Overloading the memory operations to read/write/protect 64-bit memory

Once these inline hooks are in-place on the 64-bit syscall stubs, any application utilizing Heaven’s Gate will be properly intercepted. This hooking technique is very invasive and complicated and can still be bypassed if a sample was to directly execute a syscall instruction rather than using the 64-bit module’s syscalls stub. Therefore, a driver or hypervisor is more suitable to detect this evasion technique. Instead we can focus on the more common byte restoration evasion techniques and look for a way to hook the WOW64 layer itself. This doesn’t involve assembly modifications at all.

Hooking WOW64 via LogService

Thinking back to the WOW64 layer’s execution flow we know that all calls which are sent through the Wow64SystemServiceEx routine may invoke the routine Wow64LogSystemService if the logging DLL is loaded. We can utilize this logging DLL and routine to implement hooks which can be written the exact same way as inline hooks, without modifying any assembly.

The first step to implementing this is to force all API call paths through the Wow64SystemServiceEx routine so that the log routine may be called. Remember earlier that those that support TurboThunks will not take this path. Lucky for us we know that any TurboThunk entry that points to TurboDispatchJumpAddressEnd will take this path. Therefore, by pointing every entry in the TurboThunk table to point at that address, the desired behavior is achieved. Windows kindly implements this patching via wow64cpu!BTCpuTurboThunkControl as shown in Figure 17.

Figure 17: Patching the TurboThunk table is implemented for us

Note that in previous Windows versions the module which exported this and how it did is different to Windows 10, version 2004. After invoking this patch routine all syscall paths through WOW64 go through Wow64SystemServiceEx and we can focus on crafting a logging DLL that man-in-the-middles (MITMs) all calls. There are a couple of challenges to be considered here:

  1. How do we determine which system call is currently occurring from the logging DLL?
  2. How are callbacks written? Wow64log is 64-bit DLL, we’d like a 32-bit callback.
    • Is shellcode required, or can we make nice C style function callbacks?
  3. What APIs may we call? All that’s loaded is 64-bit ntdll.

The first concern is rather easy, from within the wow64log DLL we can read the syscall number from the syscall stubs to create a map of number to name. This is possible because syscall stubs always start with the same assembly and the syscall number is at a static offset of 0x4. Figure 18 shows how we can then compare the values in this map against the syscall number passed to Wow64LogSystemService’s parameter structure WOW64_LOG_SERVICE.

typedef uint32_t* WOW64_ARGUMENTS;
      uint64_t BtLdrEntry;
      WOW64_ARGUMENTS Arguments;
      ULONG ServiceTable;
      ULONG ServiceNumber;
      NTSTATUS Status;
      BOOLEAN PostCall;

Wow64LogSystemService(WOW64_LOG_SERVICE* service)
     for (uint32_t i = 0; i < LAST_SYSCALL_ID; i++) {
        const char* sysname = SysCallMap[i].name;
        uint32_t syscallNum = SysCallMap[i].SystemCallNumber;
        if (ServiceParameters->ServiceNumber != syscallNum)
        //LOG sysname

Figure 18: Minimal example of determining which syscall is occurring—in practice the service table must be checked too

Writing callbacks is a bit more challenging. The wow64log DLL is executing in 64-bit mode and we’d like to be able to write callbacks in 32-bit mode since it’s very easy to load additional 32-bit modules into a WOW64 process. The best way to handle this is to write shellcode which is capable of transitioning back to 32-bit mode, execute the callback, then go back to 64-bit mode to continue execution in the wow64log DLL. The segment transitions themselves are rather easy at this point, we know we just need to use 0x23 or 0x33 segment selectors when jumping. But we also need to deal with the calling convention differences between 64-bit and 32-bit. Our shellcode will therefore be responsible for moving 64-bit arguments’ register/stack slots to the 32-bit arguments register/stack slots. Enforcing that 32-bit callbacks may only be __cdecl makes this easier as all arguments are on the stack and the shellcode has full control of stack layout and cleanup. Figure 19 shows the locations of the arguments for each calling convention. Once the first 4 arguments are relocated all further arguments can be moved in a loop since it’s simply moving stack values into lower slots. This is relatively easy to implement using external masm files in MSVC. Raw bytes will need to be emitted at points rather than using the assembler due to the mix of architectures. Alternatively, GCC or Clang inline assembly could be used. ReWolf’s work achieves the opposite direction of 32-bit -> 64-bit and implements the shellcode via msvc inline asm. X64 MSVC doesn’t support this and there are complications with REX prefixes when using that method. It’s nicer to use external masm files and rely on the linker to implement this shellcode.

Arg Number

Cdecl Location

Fastcall Location

Special Case?


[ebp + 8]




[ebp + 12]




[ebp + 16]




[ebp + 20]




[ebp + 24]

[rbp + 32 + 8]



[ebp + 28]

[rbp + 32 + 16]



[ebp + 32]

[rbp + 32 + 24]


Figure 19: Cdecl vs Fastcall argument positions

Once this shellcode is written and wrapped into a nice C++ function, it’s possible for the wow64log DLL to invoke the callback via a simple C style function pointer call shown in Figure 20.

Figure 20: call_function32 invokes shellcode to call a 32-bit callback from the 64-bit logging DLL

From within the 32-bit callback any desired MITM operations can be performed, but restrictions exist on which APIs are callable. Due to the context saving that the WOW64 layer performs, 32-bit APIs that would re-enter the WOW64 layer may not be called as the context values would be corrupted. We are therefore limited to only APIs that won’t re-enter WOW64, which are those that are exported from the 64-bit ntdll. The NtWriteFile export may be used to easily write to stdout or a file, but we must re-enter the 64-bit execution mode and do the inverse argument mapping as before. This logging routine can be called from within the 32-bit callbacks and is shown in Figure 21 and Figure 22.

Figure 21: call_function64 invokes shellcode to call the 64bit WriteFile from with the 32bit callback

Figure 22: 32bit callbacks must log via routines that only call non-reentrant WOW64 APIs

The result is clean looking callback stubs that function exactly how inline hooks might, but with zero assembly modifications required. Arguments can easily be manipulated as well, but the return status may not be modified unless a little stack walk hackery is implemented. The only other consideration is that the wow64log DLL itself needs to be carefully crafted to not build with any CRT mechanisms. The flags required are:

  • Disable CRT with /NODEFAULT LIB (all C APIs now unavailable), set a new entry point name to not init CRT NtDllMain
  • Disable all CRT security routines /GS-
  • Disable C++ exceptions
  • Remove default linker libraries, only link ntdll.lib
  • Use extern “C” __declspec(dllimport) <typedef> to link against the correct NtApis

An example of a program hooking its own system calls via wow64log inline hooks is shown in Figure 23.

Figure 23: Demonstration of inline hooks in action


Using inline WOW64 hooks, wow64log hooks, and kernel/hypervisor hooks, all techniques of usermode hook evasion can be identified easily and automatically. Detecting which layers of hooks are skipped or bypassed will give insight into which evasion technique is employed. The identifying table is:

Evasion Mode

32bit Inline


64bit Inline


Prologue Restore

Heavens Gate sys-stub

Heavens Gate direct syscall

Structure Appendix

  USHORT Flags;
  USHORT MachineType;
  WOW64_CONTEXT Context;
  char ContextEx[1024];

  unsigned __int32 SystemCallNumber : 12;
  unsigned __int32 ServiceTableIndex : 4;
  unsigned __int32 TurboThunkNumber : 5;
  unsigned __int32 AlwaysZero : 11;
#pragma pack(push, 1)
  DWORD ControlWord;
  DWORD StatusWord;
  DWORD TagWord;
  DWORD ErrorOffset;
  DWORD ErrorSelector;
  DWORD DataOffset;
  DWORD DataSelector;
  BYTE RegisterArea[80];
  DWORD Cr0NpxState;
#pragma pack(pop)

#pragma pack(push, 1)
struct _WOW64_CONTEXT
  DWORD ContextFlags;
  DWORD Dr0;
  DWORD Dr1;
  DWORD Dr2;
  DWORD Dr3;
  DWORD Dr6;
  DWORD Dr7;
  DWORD SegGs;
  DWORD SegFs;
  DWORD SegEs;
  DWORD SegDs;
  DWORD Edi;
  DWORD Esi;
  DWORD Ebx;
  DWORD Edx;
  DWORD Ecx;
  DWORD Eax;
  DWORD Ebp;
  DWORD Eip;
  DWORD SegCs;
  DWORD EFlags;
  DWORD Esp;
  DWORD SegSs;
  BYTE ExtendedRegistersUnk[160];
  M128A Xmm0;
  M128A Xmm1;
  M128A Xmm2;
  M128A Xmm3;
  M128A Xmm4;
  M128A Xmm5;
  M128A Xmm6;
  M128A Xmm7;
  M128A Xmm8;
  M128A Xmm9;
  M128A Xmm10;
  M128A Xmm11;
  M128A Xmm12;
  M128A Xmm13;
  M128A Xmm14;
  M128A Xmm15;
#pragma pack(pop)

CIO Association of Canada expands its footprint with new Montreal chapter

The CIO Association of Canada (CIOCAN), which represents CIOs, CISOs and IT executives across the country, is launching a new chapter in Montreal. This initiative follows the incubation of the Montreal base for CIOCAN in collaboration with the Ottawa chapter. “In 2018, we reached out to our peers in Montreal and forged the connections that make…

The post CIO Association of Canada expands its footprint with new Montreal chapter first appeared on IT World Canada.

6 ways to overcome work from home distractions – Forbes

Constant distractions pose one of the biggest challenges to working from home. However, you can overcome them through effective work planning in addition to implementing the following tips in your home office. Fix a work schedule: An effective way to overcome distractions when working remotely or from home includes sticking to the work schedule and…

The post 6 ways to overcome work from home distractions - Forbes first appeared on IT World Canada.

Unravel the XDR Noise and Recognize a Proactive Approach

Cybersecurity professionals know this drill well all too well. Making sense of lotof information and noise to access what really matters. XDR (Extended Detection & Response) has been a technical acronym thrown around in the cybersecurity industry with many notations and promises. This can be intriguing and nagging for cybersecurity professionals who are heads down defending against the persistent adversaries. The intent of this blog is to clarify XDR and remove the noise and hype into relevant and purposeful cybersecurity conversations with actionsAnd observe the need for a proactive approach. 

Let’s begin with what does XDR refer to and its evolution. As noted earlier, XDR stands for Extended Detection and Response. “extended” is going beyond the endpoint to network and cloud infrastructure. You will find this cross-infrastructure or cross-domain capability is the common denominator for XDR XDR is the next evolution of a solid Endpoint Detection and Response (EDR). Ironically it was a term introduced by a network security vendor with aspirations to enter the emerging Security Operations market.  

A Look at the Industry Point of Views 

Industry experts have weighed in on this XDR capability for cybersecurity. Gartner’s definition, XDR is “a SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system that unifies all licensed components.” Gartner notes three primary requirements of an XDR system are; centralization of normalized data primarily focused on the XDR vendors’ ecosystem, correlation of security data and alerts into incidents and centralized incident response capability that can change the state of individual security products as part of incident response or security policy setting. If you want to hear more from Gartner on this topic, check out the report. 

ESG defines XDR as an integrated suite of security products spanning hybrid IT architectures, designed to interoperate and coordinate on threat prevention, detection and response. In other words, XDR unifies control points, security telemetry, analytics, and operations into one enterprise system. 

Forrester views XDR as the next generation of Endpoint Detection and Response to evolve to by integrating endpoint, network and application telemetry. The key goals include empowering analysts with incident-driven analytics for root cause analysis, offer prescriptive remediation with the ability to orchestrate it and map uses cases MITRE ATT&CK techniques and chain them into complex queries that describe behaviors, instead of individual events. 

XDR Themes 

The common XDR themes from these XDR discussions are multiple security functions integrated and curated data across the control vectors all working together to achieve better security operational efficiencies while responding to a threat. Cross control points make sense since the adversary movement is erratic.  Emphasis is on removing complexity and offering better detection and understanding of the risk in the environment and quickly sorting through a possible response.  The range of detect and response capabilities also suggest that it cannot be done by one exclusive vendor. Many advocates an integrated partnership approach to unify defenses and streamline efforts across domains and vectors. This is not a new concept to connect the security disciplines to work together, as matter fact, McAfee has been professing and delivering on Together is Power motto for some time.  

Another common XDR theme is the promise to accelerate investigation efforts by offering automatic analysis of findings and incidents to get closer to a better assessment. This makes your reactive cycles potentially less frequent 

Integrating security across the enterprise and control points and accelerating investigations are critical functions. Does it address organizational nuances like is this threat a high priority because it is prevalent in my geo and industry and it’s impacting target assets with highly sensitive data.  Prioritization should also be an XDR theme but not necessarily noted in these XDR discussions. 

Net Out the Core XDR Functions 

After distilling the many point of views and the themes on XDR, it seems the core functions all focus on improving security operations immensely during an attack.  So, it’s reactive function. 

XDR Core & Baseline functions  Why? 
Cross infrastructure—comprehensive vector coverage  Gain comprehensive visibility & control across your entire organization and stop operating in silos 

Remove disparate efforts between tools, data and functional areas 

Distilled data and correlated alerts across the organization  Remove manual discover and make sense of it all 
Unified management with a common experience  From a common view or starting point removes the jumping between consoles and data pools to assure  
Security functions automatically exchange and trigger actions  Some security functions need to be automated like detection or response  
Advanced functions—not noted in many XDR discussions  Why? 
Actionable intelligence on potentially relevant threats  Allow organizations to proactively harden their environment before the attack 
Rich context that includes threat intelligence and organizational impact insight  Organizations can prioritize their threat remediation efforts on major impact to the organization 
Security working together with minimal effort  Simply tie a range of security functions together to create a united front and optimize security investments 


Key Desired Outcomes 

The end game is better security operational efficiencies. This can be expressed in handy outcome check list perhaps helpful when assessing XDR solutions. 

Visibility  Control 
More accurate detection  More accurate prevention 
Adapt to changing technologies & infrastructure  Adapt to changing technologies & infrastructure 
Less blind spots  Less gaps 
Faster time to detect (or Mean Time to Detect-MTTD)  Faster time to remediate (or Mean Time to Respond-MTTR) 
Better views and searchability  Prioritized hardening across portfolio—not isolated efforts 
Faster & more accurate investigations (less false positive)   Orchestrate the control across the entire IT infrastructure 


A More Proactive Approach is Needed 

McAfee goes beyond the common XDR capabilities in the recently announced MVISION XDR and offers unmatched proactivity and prioritization producing smarter and better security outcomes. This means your SOC spends less time on error-prone reactive fire drills with weeks of investigation.  SOCs will respond and protect what counts a lot quicker. Imagine getting ahead of the adversary before they attack.  

Cyber Attack Lifecycle 

Solution or Approach?  

Is XDR a solution or product to be bought or an approach an organization’s must rally their security strategy to take?  Honestly it can be both.  Many vendors are announcing XDR products to buy or XDR capabilities An XDR approach will shift processes and likely to merge and encourage tighter coordination between different functions like SOC analysts, hunters, incident responders and IT administrators. 

Is XDR for everyone? 

It depends on the organizations’ current cybersecurity maturity and readiness to embrace the breadth and required processes to obtain the SOC efficiency benefits. With the promise to correlate data across the entire enterprise implies some of the mundane and manual efforts to make sense of data into a better and actionable understanding of a threat are removed.  Now this is good for organizations on both spectrums.  Less mature organizations who do not have resources or expertise and do not consume data intelligence to shift through will appreciate this correlation and investigation stepbut can they continue the pursuit of what does this mean to me. Medium to high mature cybersecurity organizations with expertise will not need to do the manual work to make sense of data. The difference with mature organizations comes with the next steps to further investigate and to decide on the remediation steps. Less mature organizations will not have the expertise to accomplish this. So, the real make a difference moment is for the more mature organization who can move more quickly to a response mode on the potential threat or threat in progress.  

Your XDR Journey 

If you are a medium to high mature cybersecurity organization, the question comes how and when. Most organizations using an Endpoint Detection and Response (EDR) solution are likely quite ready to embrace the XDR capabilities since their efforts are already investigating and resolving endpoint threatsIt’s time to expand this effort gaining better understanding of the adversary’s movement across the entire infrastructure.  If you are using McAfee MVISION EDR you are already using a solution with XDR capabilities since it digests SIEM data from McAfee ESM or Splunk (which means it goes beyond the endpoint, a key XDR requirement.)  

Hope this blog removed the jargon and fog around XDR and offers actionable considerations for your organization to boost their SOC efforts. Don’t miss the XDR session at our MPOWER conferenceEmbrace the X-factor: Where to Start Your XDR Journey. 



The post Unravel the XDR Noise and Recognize a Proactive Approach appeared first on McAfee Blogs.

Worried About SaaS Misconfigurations? Check These 5 Settings Everybody Misses

Enterprises depend on SaaS applications for countless functions, like collaboration, marketing, file sharing, and more. But problematically, they often lack the resources to configure those apps to prevent cyberattacks, data exfiltration, and other risks. Catastrophic and costly data breaches result from SaaS security configuration errors. The Verizon 2020 Data Breach Investigations Report found

Campari staggers to its feet following $15 million Ragnar Locker ransomware attack

Campari was targeted by hackers using the Ragnar Locker ransomware. According to some reports, the malware attack managed to encrypt data on 24 of the company’s servers around the world, and the hackers responsible have demanded a cryptocurrency ransom worth $15 million.

Computer Manufacturing Company Compal Discloses Security Incident

Computer manufacturing company Compal Electronics announced that it had suffered a security incident involving some of its systems. Qingxiong Lu, deputy manager director of Compal, told United News Network on November 9 that the company had experienced a security incident. In his explanation of the event, Qingxiong identified that the incident had mainly affected Compal’s […]… Read More

The post Computer Manufacturing Company Compal Discloses Security Incident appeared first on The State of Security.

Lessons from Teaching Cybersecurity: Week 6

As I had mentioned previously, this year, I’m going back to school. Not to take classes, but to teach a course at my alma mater, Fanshawe College. I did this about a decade ago and thought it was interesting, so I was excited to give it another go. Additionally, after a friend mentioned that their […]… Read More

The post Lessons from Teaching Cybersecurity: Week 6 appeared first on The State of Security.

New Book! The Best of TaoSecurity Blog, Volume 3



I published a new book!

It's in the Kindle Store, and if you have an Unlimited account, it's free. 

I also published a print edition, which is 485 pages. 

Book Description

The book features the following description on the back cover:

Since 2003, cybersecurity author Richard Bejtlich has been publishing posts on TaoSecurity Blog, a site with 15 million views since 2011. Now, after re-reading over 3,000 stories and approximately one million words, he has selected and republished the very best entries from 17 years of writing, along with commentaries and additional material. 

In the third volume of the TaoSecurity Blog series, Mr. Bejtlich addresses the evolution of his security mindset, influenced by current events and advice from his so-called set of "wise people." He talks about why speed is not the key to John Boyd's OODA loop, and why security strategies designed for and by the "security 1%" may be irrelevant at best, or harmful at worst, for the remaining "99%". His history section explores the origins of the terms threat hunting and indicators of compromise, and reveals who really created the quote "there are two types of companies." His chapter on law highlights traps that might catch security teams, with advice to chief information security officers.

This volume contains some of Mr. Bejtlich’s favorite posts, such as Marcus Ranum's answer to what happens when security teams confront professionals, or how the Internet continues to function despite constant challenges, or reactions to comments by Dan Geer, Bruce Schneier, Marty Roesch, and other security leaders. Mr. Bejtlich has written new commentaries to accompany each post, some of which would qualify as blog entries in their own right.  Read how the security industry, defensive methodologies, and strategies to improve national security have evolved in this new book, written by one of the authors who has seen it all and survived to blog about it.

Writing the Series

Although I had written and self-published a book in early 2019, I had used Blurb and stayed in print format. 

For this new project, I wanted to publish "reflowable" (not print replica) Kindle editions, along with print versions, through Amazon. 

I started the project in September 2019 by labelling 300 or so out of the 3,050 blog posts as candidates for inclusion in a "best of" book. I quickly realized that "only" 300 posts, plus new material and commentary, would result in a very large project, so I decided to break it into three volumes.

I created twelve categories and began sorting and commenting on the posts in March 2020. I decided to assign four categories to each volume, with an "appendices" category for the last volume if necessary.

I chose the 5.5 inch by 8.5 inch "statement" print size since it was supported by Google Docs and was a standard print size for Amazon.

Eventually I selected almost 375 posts for the book and began the real work!

I published volume 1 in May 2020. The print edition features 85,030 words in 357 pages, or about 238 words per page. 

I published volume 2 in September 2020. The print edition features 96,288 words in 429 pages, or about 224 words per page

Now, volume 3 has arrived in November 2020. The print edition features 90,190 words in 485 pages, or about 185 words per page.

In total, the project resulted in 271,508 words over 1,271 pages, or about 214 words per page.

What's Next?

Originally I wanted to add a few items outside TaoSecurity Blog to the third volume, in a section called "Appendices." As I discovered and collected this material, I realized that adding it would essentially double the size of the third volume. As it was over 400 pages at that time, I decided I would save most of this material for another project.

That other project is Beyond TaoSecurity Blog, Volume 1: Columns, Papers, PhD Work, and Testimonies. At the moment, I believe I have a handle on what to include in that title. I don't expect to have a volume 2, but I thought it best to give this a volume number as I may have more material to publish in the future.

My goal is to publish this "Beyond" book during the next few weeks -- perhaps during or after Thanksgiving. 


I wrote this series of books because I fear that this blog has become too unwieldy for its own good. Revisiting 17 years of posts, adding commentaries, and collecting related material has helped me better understand my own journey in security. The new "Beyond" book reaches a bit farther past the three blog volumes and includes material never before published, primarily from my abandoned PhD effort. I'll have more to say when I published that book before the end of the year.

If you've read any of the books in the TaoSecurity Blog series, I would great appreciate a positive review! Thank you.

RDP and the remote desktop

There are two sides to the shift to remote work. On one side, you need to ensure that your people have access to equipment that will allow them to perform their day-to-day tasks. On the other, there needs to be a way to connect back to company resources that will help workers complete those tasks.

One solution to both of these aspects that has proven useful is remote desktop technologies. These technologies allow a user to log into a computer remotely and operate it just as though they were sitting in front of it.

Remote desktop technology is not new and there are a number of solutions available, ranging from platform-independent implementations, such as VNC, to third-party services that make remote desktop connections a breeze to set up and use.

One remote desktop implementation that stands out is Window’s Remote Desktop Services, which relies on the Remote Desktop Protocol (RDP) for communication. Being baked into the Windows operating system makes enabling the feature and connecting to it very simple.

RDP as a target

As convenient as this may be, remote desktop solutions—and RDP in particular—come with their share of security concerns. Over the years RDP has been targeted in a variety of ways. Brute-force attacks and login attempts using stolen credentials are a natural concern. The protocol had also suffered its fair share vulnerabilities, allowing for man-in-the-middle attacks and multiple remote code  execution vulnerabilities.

The prominence of RDP attacks led the FBI to release an alert about the protocol in late 2018, pointing out that malicious targeting of the protocol was on the rise. The report discussed how malicious actors leveraging ransomware, such as CrySIS and SamSam, were reportedly gaining entry into networks by leveraging poorly configured RDP setups, and even buying and selling stolen RDP credentials on the dark web.

Then, in May 2019, a vulnerability in the way Remote Desktop Services handles RDP requests was disclosed. Dubbed BlueKeep, Microsoft noted that the vulnerability was likely ‘wormable’ and could be used by malware to spread from one unpatched system to another, much like WannaCry had done two years earlier. In the subsequent months two more remote code execution vulnerabilities where discovered in RDP. While no such worm has materialized, RDP had gained significant attention as an avenue into a network.

Frequency of attack

Just how frequently is RDP targeted? It’s a difficult question to answer, simply because of how hard it can be to distinguish malicious from legitimate traffic. Since stolen credentials and brute-force login attempts are often used, unauthorized access will often look like legitimate log-in events.

There are a few ways we can qualify the level of RDP attacks. Nmap is a popular network scanning utility that’s often used to check for open ports. The utility includes a list of commonly scanned ports that weights them by how likely they are found to be open. Here are the top 10 TCP ports most likely to be found open, based on Nmap’s current weightings:

Top 10 open TCP ports (Nmap)
Top 10 open TCP ports (Nmap)

RDP ranks seventh overall and is the highest-ranked proprietary port likely to be found open. What is interesting is that only system ports, used by well-known services, come before RDP. The only other proprietary protocol in the list is SMB, the Microsoft file-sharing protocol exploited by WannaCry, which we’ve discussed previously.

Further highlighting concerns about RDP attacks, is the large number of RDP ports that are exposed directly to the Internet. According to data collected from shodan.io, over four million systems that are exposed directly to the internet have TCP port 3389 open.

Of course, just because a port is open doesn’t mean that attackers are regularly targeting it. In order to investigate further, let’s take a look at data from Cisco Secure Endpoint. Here, we’ll specifically look at the exploit prevention technology included, which includes two signatures for detecting BlueKeep attacks.

The first of these signatures will alert when someone scans TCP port 3389 to see if a system is vulnerable to BlueKeep (“CVE-2019-0708 scanning attempt detected”). The second signature alerts when someone attempts to exploit it (“CVE-2019-0708 detected”). We’re using the same methodology in the following chart to arrive at these numbers as we did in the recent Threat Landscape Trends blogs, examining the number of organizations that encountered these signatures each month.

Percentage of organizations seeing BueKeep-related alerts
Percentage of organizations seeing BueKeep-related alerts

Overall, 31-34 percent of organizations received at least one BlueKeep alert each month in the first half of 2020. What’s interesting is that the type of alert shifted as the year progressed. In January, almost two-thirds of RDP alerts were exploit attempts; by June more than two-thirds were scanning attempts.

On the surface, this appears to indicate that, while attackers may have found initial success in exploiting the port outright earlier in the year, they may have found it more efficient to test if a system was exploitable first. Or it simply worked better in avoiding detection.

One caveat is that within these numbers there will be some alerts triggered by legitimate vulnerability scanners. Such tools are used by security teams to locate vulnerable systems so that they can be addressed. These tools will likely trigger a “scanning attempt detected” signature. In short, not all scanning alerts in the chart above are coming from malicious actors.

Having said that, there are a number of attack frameworks and dual-use tools, such as Metasploit, that have incorporated the BlueKeep exploit. This has significantly lowering the bar for entry when it comes to carrying out successful attacks against RDP enabled systems.

Finally, while around a third of organizations encountered RDP-related alerts each month, the organizations that did were often hammered with alerts. Looking at alerts overall, an incredible proportion of 80-88 percent of exploit alerts picked up by our exploit prevention technology were related to this RDP exploit.

Percentage of exploit prevention related alerts associated with the BlueKeep exploit
Percentage of exploit prevention related alerts associated with the BlueKeep exploit

To use or not to use

Perhaps the simplest way to guard against RDP attacks is to not use it. The protocol is disabled in Windows by default, meaning that unless it’s enabled, systems are not susceptible to attack.

If you’re looking for a remote desktop solution, there are a wide variety of less-targeted options available. If cost is an issue, there are even open-source alternatives, such as VNC, that offer similar feature sets.

Nevertheless, any remote desktop solution if compromised through a vulnerability, or by using stolen credentials, gives an attacker a toe hold within an organization through which malicious tools can be installed, or privileges escalated.

Remote desktop access may not be the best solution in the first place. Configuring VPN solutions to allow remote working employees to access to the resources they need not only frees up the network resources that would be used to mirror a desktop environment remotely, but also allows for additional layers of security.

If RDP is necessary, so employees can connect to on-site desktop computers, requiring clients to connect to a VPN first means that clients can be authenticated and scanned to ensure security compliance, plus users can be authenticated by multi-factor authentication, before connecting to RDP.

Understandably, in some organizations that rely on Remote Desktop Services, moving away from RDP may not be an option. In these cases, there are things that can be done to shore up RDP communication.

  • Do not connect RDP-enabled systems directly to the internet. Instead, use a VPN and/or proxy connections through a Remote Desktop Gateway.
  • Use strong passwords and multi-factor authentication (MFA). Stronger passwords make brute-forcing passwords difficult, while MFA adds a second layer of authentication if a password is stolen.
  • Block failed login attempts when they exceed a reasonable number. Apply policies that temporarily block IPs or disable user accounts that do so.
  • Change the RDP port. A simple way to avoid blanket scans of the default RDP port is to switch to something other than 3389.

How Cisco Security can help

Cisco’s SecureX platform provides a number of touch points for detecting and blocking RDP-based attacks, which can be viewed within one easy-to-read dashboard.

  • Cisco AnyConnect Secure Mobility Client. Using a VPN is one of the easiest and most secure methods for connecting to an organization’s network remotely. AnyConnect simplifies secure access to the company network and provides the security necessary to help keep your organization safe and protected.
  • Cisco Secure Access by Duo. Use MFA to verify that RDP connection requests are coming from trusted sources. Duo enables organizations to verify users’ identities before granting access.
  • Cisco Secure Firewall can detect and prevent RDP attacks using a number of methods, including Snort rules designed for spotting attacks leveraging the protocol.
  • Cisco Secure Endpoint. As described above, Secure Endpoint can detect and block exploit attempts against RDP, as well as block behavioral anomalies often found in RDP attacks.
  • Cisco Secure Network Analytics. Whether you use RDP or not, it’s worth monitoring network traffic for policy violations. Network Analytics can assist in detecting anomalies across your networks, flagging applications that should not be used in the environment.

Cyber Security Today – Linux ransomware strain found, a second data breach at Luxottica, Canadian health unit forgets hard drives, and more

Today's podcast reports on a new Linux ransomware strain, a second data breach at Luxottica, a Canadian health unit forgets hard drives how poorly-secured SonarQube instances lead to code theft

The post Cyber Security Today - Linux ransomware strain found, a second data breach at Luxottica, Canadian health unit forgets hard drives, and more first appeared on IT World Canada.

Hashtag Trending – Canada takes aim at streaming giants; AI helps identify COVID; Vatican enlists bots

Canada is holding streaming giants’ feet to the fire, a new AI program can spot COVID from a cough, and the Vatican is turning to bots for help to combat an onslaught of cyberattacks targeting its libraries.

The post Hashtag Trending - Canada takes aim at streaming giants; AI helps identify COVID; Vatican enlists bots first appeared on IT World Canada.

Windows 10, iOS, Chrome, Firefox and Others Hacked at Tianfu Cup Competition

Multiple software products from Adobe, Apple, Google, Microsoft, Mozilla, and Samsung were successfully pwned with previously unseen exploits in Tianfu Cup 2020, the third edition of the international cybersecurity contest held in the city of Chengdu, China. "Many mature and hard targets have been pwned on this year's contest," the event organizers said. "11 out of 16 targets cracked with 23