The McAfee blog released an article about how a current spear phishing attack (T1566) looks like in detail:
More details about this attack can be found in the McAfee blog article.

You can uninstall standalone installations of the EC via the Windows control panel under Programs and Features.
If the EC was automatically installed as part of a PRTG installation, you can use the PRTG Enterprise Console Removal Tool as of PRTG 20.2.58 to uninstall the EC independently from the PRTG installation.Click the Windows Start menu and select PRTG Network Monitor, then click Remove PRTG Enterprise Console to remove the EC from your PRTG core server system.
Source: https://kb.paessler.com/en/topic/85851-how-to-uninstall-the-prtg-enterprise-console-from-the-prtg-server
Dir *.CHK | rename-item -newname { [io.path]::ChangeExtension($_.name, "AVI") }
Dir *.WRI | rename-item -newname { [io.path]::ChangeExtension($_.name, "AVI") }
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
[...]
- Cold standby. A secondary data center that can provide availability within hours or days.
- Warm standby. A secondary data center that can provide availability within minutes or hours.
- Hot standby. A secondary data center that can provide availability within seconds or minutes.
Important: Available network bandwidth and latency are major considerations when you are using a failover approach for disaster recovery. We recommend that you consult with your SAN vendor to determine whether you can use SAN replication for SQL databases or another supported mechanism to provide the hot standby level of availability across data centers.
We had two datacenters.
Given the above, we have from ~20%-~40% to ~97% loss from the theoretical transmission rate. Keep in mind that when moving from a simple signal to a more heavy and concurrent transmission, we also have to deal with the bandwidth limitation. This adds additional cost. All in only 400Km distance.
- The connection between the two was with fiber
- Distance Km ~400, but now we MUST consider the distance to go and come back. This because in case of real communication, we have not only the send, but also the receive packages.
- Theoretical time at light-speed =2.66ms (2 ways)
- Ping = 3.10ms (signal traveling at ~80% of the light speed) as if the signal had traveled ~930Km (full roundtrip 800 Km)
- TCP/IP best at 48K = 4.27ms (~62% light speed) as if the signal had traveled ~1,281km
- TCP/IP best at 512K =37.25ms (~2.6% light speed) as if the signal had traveled ~11,175km
This is not all. Within the 400km we were also dealing with data congestions, and in some cases the tests failed to provide the level of accuracy we required due to transmission failures and too many packages retry.
[...]
What Is the Right Thing To Do?
The right solution is easier than the wrong one, and there are already tools in place to make it work efficiently. Say you need to define your HA solution between the East and West Coast, or between Paris and Frankfurt. First of all, identify the real capacity of your network in each DC. Then build a tightly coupled database cluster in location A and another tightly coupled database cluster in the other location B. Then link them using ASYNCHRONOUS replication.
![]() |
| Picture from YouTube Video "The vSphere CPU Scheduler" of "TrainerTests" |
In versions 5.x and below, trusted hosts configured by an administrator user only allow access from certain IP addresses configured in trusted hosts, to all services configured on the interface, including ping.
From version 6.0 onwards ping service on management interfaces are not included within the scope of trusted hosts. This means that you will be able to ping the interface from an IP that is not included within trusted hosts.
In order to only allow trusted hosts to be able to ping the interface and deny everyone else, you will need to configure a Local In Policy as below.
CLI configuration:
System > Administrators >
config system admin
edit "admin"
set trusthost1 172.26.73.48 255.255.255.255
set accprofile "super_admin"
set vdom "root"
next
endConfiguring address and address group as per the trusted hosts:
config firewall addressConfiguring Firewall local in policies:
edit "trusted-1"
set type ipmask
set comment ''
set visibility enable
set associated-interface ''
set color 0
set allow-routing disable
set subnet 172.26.73.48 255.255.255.255
next
end
config firewall addrgrp
edit "trusted_grp"
set member "trusted-1"
set comment ''
set visibility enable
set color 0
next
end
config firewall local-in-policy
edit 2
set intf "port1"
set srcaddr "trusted_grp"
set dstaddr "all"
set action accept
set service "PING"
set schedule "always"
set status enable
set comments ''
next
edit 1
set intf "port1"
set srcaddr "all"
set dstaddr "all"
set action deny
set service "PING"
set schedule "always"
set status enable
set comments ''
next
end
Before configuring the local in policy:
diagnose sniffer packet any 'host 172.26.73.78 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
3.647787 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
3.647850 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply
4.651341 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
4.651383 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply
5.657949 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
5.657992 port1 out 10.5.22.114 -> 172.26.73.78: icmp: echo reply
After configuring the local in policies:
diagnose sniffer packet any 'host 172.26.73.78 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
4.264950 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
8.904217 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
13.906576 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
18.893835 port1 in 172.26.73.78 -> 10.5.22.114: icmp: echo request
trace_id=22 func=print_pkt_detail line=5497 msg="vd-root:0 received a packet(proto=1, 172.26.73.78:1->10.5.22.114:2048) from port1. type=8, code=0, id=1, seq=335."
id=20085 trace_id=22 func=init_ip_session_common line=5657 msg="allocate a new session-00874fe6"
id=20085 trace_id=22 func=vf_ip_route_input_common line=2591 msg="find a route: flag=80000000 gw-10.5.22.114 via root"
id=20085 trace_id=22 func=fw_local_in_handler line=409 msg="iprope_in_check() check failed on policy 1, dropReply for the trusted host:diagnose sniffer packet any 'host 172.26.73.48 and icmp' 4
interfaces=[any]
filters=[host 172.26.73.48 and icmp]
7.239647 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
7.239743 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
8.261081 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
8.261122 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
9.276261 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
9.276321 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
10.294536 port1 in 172.26.73.48 -> 10.5.22.114: icmp: echo request
10.294588 port1 out 10.5.22.114 -> 172.26.73.48: icmp: echo reply
Turn on PowerShell Script Block Logging feature in Group Policy through Administrative Templates -> Windows Components -> Windows PowerShell.function Enable-PSScriptBlockLogging
{
$basePath = 'HKLM:\Software\Policies\Microsoft\Windows' +
'\PowerShell\ScriptBlockLogging'
if(-not (Test-Path $basePath))
{
$null = New-Item $basePath -Force
}
Set-ItemProperty $basePath -Name EnableScriptBlockLogging -Value "1"
}
Powershell-Commands will be logged in Windows Eventlog with Event-ID 4104.
1: show PID2: show statistics and state3: show connected device name and IP4: show detailed session state5: show oftp request statistics6: show cmdb device cache7: show logfwd thread stats8: show tasklist statistics9: show unreg dev cache10: log cluster bridge stats20: show forticlent end-user stats21: rebuild forticlient end-user avatar table90: reload un-reg device tree99: restart daemonProblem If you are running proxmox (e.g. proxmox v 8.4.14) on a Intel NUC and it sporadically crashes with the following entries in the log...