Zero Day May
Take Caution With Curiosity
Have Fun
I have been interested in cyberwarfare and reverse engineering systems since I first installed Ubuntu on a home server I built. One of the senior network engineers for (at the time) Telemundo, encouraged the switch to Linux. He opened Pandora's box and told me to have fun.
Fast forward. Now. I run a company that does research and development as a member of the defense industrial base.
I always have enjoyed full spectrum security research. Recon, OSINT and mapping out and learning the nature of connected things is fascinating. Maltego, Spiderfoot HX and the OSINT framework are good friends of mine. I was never much into the exploitation elements of offensive security. I did however enjoy finding network paths to things that on first glance appear out of reach.
It was not until I got severely compromised that I found graphing algorithms to be one of the most profoundly useful tools. Yesterday I got a ping in a group chat about a container image that had an IOC from a K3s container image tar with an IOC pointing to Mirai malware. Mirai is a malware that turns networked devices running Linux into remotely controlled bots that can be used as part of a botnet in large-scale network attacks. For the purposes of this article I started a fresh hunt on VirusTotal's Enterprise platform to revalidate the paths of correlation to ensure I had not concluded anything prematurely.
This is the tar of image: docker.io/rancher/k3s:v1.26.4-k3s1 with digest sha256:ff61834317d7f0a58e3366546fe301b7e6802a36c39126de686d9eb9e64f81cf.
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 736,
"digest": "sha256:957f179a4d04e16e0ce03364252e6ff75b9eed52d37120ce9d08b4f51000cf3c",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 736,
"digest": "sha256:ab2fea32633450d60770c5eeb2641e5b68268a97e26471f16182f11f818ea2c2",
"platform": {
"architecture": "arm64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 736,
"digest": "sha256:be8e7b1db6d66b8681ea01ffb335808ebf4bf171511e8c2ca3e72a59b8ac0270",
"platform": {
"architecture": "arm",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 736,
"digest": "sha256:f547b829c8f470229eabc9fdb26edbdbb33e14a0be08bb33077350499f840cd4",
"platform": {
"architecture": "s390x",
"os": "linux"
}
}
]
}
What this means:
This JSON code represents a Docker Image Manifest List, also known as a "fat manifest." It is a descriptor pointing to specific image manifests for one or more platforms. It's used to support multi-platform images in Docker and other container technologies.
Here's a breakdown of the key elements:
schemaVersion: This indicates the version of the schema that the manifest is using. In this case, it's version 2.mediaType: This is the MIME type of the manifest list. It's used to specify the type of data being sent. Here, it's set to "application/vnd.docker.distribution.manifest.list.v2+json," which is the media type for Docker Image Manifest List.
manifests: This is an array of objects, each representing a manifest for a specific platform. Each object contains the following properties:
mediaType: This is the MIME type for the manifest. It's set to "application/vnd.docker.distribution.manifest.v2+json," which is the media type for Docker Image Manifest.size: This is the size of the manifest in bytes.digest: This is the SHA256 checksum of the manifest, ensuring data integrity.
platform: This object describes the platform that the image is built for. It includes:
architecture: This is the CPU architecture that the image is built for, such as "amd64," "arm64," "arm," or "s390x."os: This is the operating system that the image is built for. In this case, all are built for "linux."
In summary, this Docker Image Manifest List describes four different Docker images, each built for a different CPU architecture but all for the Linux operating system.
Pivoting
This pivot from the tar to the embedded ips shows a network call back out to 224.0.0.0. This is interesting because there is one finding associated with this otherwise reserved multicast address for a local subnet. In a botnet that kind of makes sense as all bots act uniformly as a single network.
This particular file's call to this address then calls this cluster of awful:
Remember these are IOCs, indicators of comprise, not silver bullets or smoking guns. Digging deeper to get a full spectrum view is the only reliable means to have confidence in the findings.
So, pulling the thread on multicast and some interesting strings pulled from the hex representation of the tar file which is
HEX Converted to ASCII
0040755
0000000
00000000000
14420104137
010014
bin/.links
0100644
00000013654
011143
[ coreutils
[[ busybox
addgroup busybox
adduser busybox
ar busybox
arch busybox
arp busybox
arping busybox
ash busybox
aux/arptables xtables-nft-multi
aux/arptables-nft xtables-nft-multi
aux/arptables-nft-restore xtables-nft-multi
aux/arptables-nft-save xtables-nft-multi
aux/arptables-restore xtables-nft-multi
aux/arptables-save xtables-nft-multi
aux/ebtables xtables-nft-multi
aux/ebtables-nft xtables-nft-multi
aux/ebtables-nft-restore xtables-nft-multi
aux/ebtables-nft-save xtables-nft-multi
aux/ebtables-restore xtables-nft-multi
aux/ebtables-save xtables-nft-multi
aux/ip6tables iptables-detect.sh
aux/ip6tables-apply iptables-apply
aux/ip6tables-legacy xtables-legacy-multi
aux/ip6tables-legacy-restore xtables-legacy-multi
aux/ip6tables-legacy-save xtables-legacy-multi
aux/ip6tables-nft xtables-nft-multi
aux/ip6tables-nft-restore xtables-nft-multi
aux/ip6tables-nft-save xtables-nft-multi
aux/ip6tables-restore iptables-detect.sh
aux/ip6tables-restore-translate xtables-nft-multi
aux/ip6tables-save iptables-detect.sh
aux/ip6tables-translate xtables-nft-multi
aux/iptables iptables-detect.sh
aux/iptables-legacy xtables-legacy-multi
aux/iptables-legacy-restore xtables-legacy-multi
aux/iptables-legacy-save xtables-legacy-multi
aux/iptables-nft xtables-nft-multi
aux/iptables-nft-restore xtables-nft-multi
aux/iptables-nft-save xtables-nft-multi
aux/iptables-restore iptables-detect.sh
aux/iptables-restore-translate xtables-nft-multi
aux/iptables-save iptables-detect.sh
aux/iptables-translate xtables-nft-multi
aux/modprobe ../busybox
aux/mount ../busybox
aux/xtables-monitor xtables-nft-multi
awk busybox
b2sum coreutils
base32 coreutils
base64 coreutils
basename coreutils
basenc coreutils
bc busybox
bridge cni
bunzip2 busybox
bzcat busybox
cat coreutils
chattr busybox
chcon coreutils
chgrp coreutils
chmod coreutils
chown coreutils
chroot coreutils
chrt busybox
chvt busybox
cksum coreutils
clear busybox
cmp busybox
comm coreutils
cp coreutils
cpio busybox
crictl k3s
crond busybox
crontab busybox
csplit coreutils
ctr k3s
cut coreutils
date coreutils
dc busybox
dd coreutils
deallocvt busybox
delgroup busybox
deluser busybox
devmem busybox
df coreutils
diff busybox
dir coreutils
dircolors coreutils
dirname coreutils
dnsd busybox
dnsdomainname busybox
dos2unix busybox
du coreutils
dumpkmap busybox
echo coreutils
egrep busybox
eject busybox
env coreutils
ether-wake busybox
expand coreutils
expr coreutils
factor coreutils
fallocate busybox
false coreutils
fbset busybox
fdflush busybox
fdformat busybox
fgrep busybox
flannel cni
fmt coreutils
fold coreutils
free busybox
freeramdisk busybox
fsck busybox
fsfreeze busybox
fuser busybox
getopt busybox
getty busybox
grep busybox
groups coreutils
gunzip busybox
gzip busybox
halt busybox
hdparm busybox
head coreutils
hexedit busybox
host-local cni
hostid coreutils
hostname busybox
hwclock busybox
i2cdetect busybox
i2cdump busybox
i2cget busybox
i2cset busybox
i2ctransfer busybox
id coreutils
ifconfig busybox
ifdown busybox
ifup busybox
inetd busybox
init busybox
insmod busybox
install coreutils
ipaddr busybox
ipcrm busybox
ipcs busybox
iplink busybox
ipneigh busybox
iproute busybox
iprule busybox
iptunnel busybox
join coreutils
k3s-agent k3s
k3s-certificate k3s
k3s-completion k3s
k3s-etcd-snapshot k3s
k3s-secrets-encrypt k3s
k3s-server k3s
k3s-token k3s
kill coreutils
killall busybox
killall5 busybox
klogd busybox
kubectl k3s
last busybox
less busybox
link coreutils
linux32 busybox
linux64 busybox
linuxrc busybox
ln coreutils
loadfont busybox
loadkmap busybox
logger busybox
login busybox
logname coreutils
loopback cni
ls coreutils
lsattr busybox
lsmod busybox
lsof busybox
lspci busybox
lsscsi busybox
lsusb busybox
lzcat busybox
lzma busybox
lzopcat busybox
makedevs busybox
md5sum coreutils
mdev busybox
mesg busybox
microcom busybox
mim busybox
mkdir coreutils
mkdosfs busybox
mke2fs busybox
mkfifo coreutils
mknod coreutils
mkpasswd busybox
mktemp coreutils
more busybox
mountpoint busybox
mt busybox
mv coreutils
nameif busybox
netstat busybox
nice coreutils
nl coreutils
nohup coreutils
nologin busybox
nproc coreutils
nslookup busybox
nuke busybox
numfmt coreutils
od coreutils
openvt busybox
partprobe busybox
passwd busybox
paste coreutils
patch busybox
pathchk coreutils
pidof busybox
ping busybox
pinky coreutils
pipe_progress busybox
pivot_root busybox
portmap cni
poweroff busybox
pr coreutils
printenv coreutils
printf coreutils
ps busybox
ptx coreutils
pwd coreutils
rdate busybox
readlink coreutils
realpath coreutils
reboot busybox
reset busybox
resize busybox
resume busybox
rm coreutils
rmdir coreutils
rmmod busybox
route busybox
run-init busybox
run-parts busybox
runcon coreutils
runlevel busybox
sed busybox
seq coreutils
setarch busybox
setconsole busybox
setfattr busybox
setkeycodes busybox
setlogcons busybox
setpriv busybox
setserial busybox
sh busybox
sha1sum coreutils
sha224sum coreutils
sha256sum coreutils
sha384sum coreutils
sha3sum busybox
sha512sum coreutils
shred coreutils
shuf coreutils
sleep coreutils
sort coreutils
split coreutils
start-stop-daemon busybox
stat coreutils
strings busybox
stty coreutils
su busybox
sulogin busybox
sum coreutils
svc busybox
svok busybox
switch_root busybox
sync coreutils
sysctl busybox
syslogd busybox
tac coreutils
tail coreutils
tar busybox
tee coreutils
telnet busybox
test coreutils
tftp busybox
time busybox
timeout coreutils
top busybox
touch coreutils
tr coreutils
traceroute busybox
true coreutils
truncate coreutils
ts busybox
tsort coreutils
tty coreutils
ubirename busybox
udhcpc busybox
uevent busybox
umount busybox
uname coreutils
unexpand coreutils
uniq coreutils
unix2dos busybox
unlink coreutils
unlzma busybox
unlzop busybox
unpigz pigz
unxz busybox
unzip busybox
uptime coreutils
users coreutils
usleep busybox
uudecode busybox
uuencode busybox
vconfig busybox
vdir coreutils
vi busybox
vlock busybox
w busybox
watch busybox
watchdog busybox
wc coreutils
wget busybox
which busybox
who coreutils
whoami coreutils
xxd busybox
xz busybox
xzcat busybox
yes coreutils
zcat busybox
bin/.sha256sums
00000004214
011733
86c4da0fabec5f809ffbe725b1a307fa11b0a562d92d4dfe55355a9a9dead221 aux/ebtables-legacy
c4af716f77714aa5dd16f570a76d4fc890cbcf17d1f7c7b1bed4aff2a67a127e aux/ebtablesd
421e100da294181238c778d5129769c8645a4cd1e75223ff48dae97ab4ccfec9 aux/ebtablesu
77409a0aed24cc06c9c574fae6787e06665ad3ba4cafb127dfd87ea913723acd aux/iptables-apply
baf828389b1545c6867573daddd042df435b140ead8b2f758a3f3e3677fd4e80 aux/iptables-detect.sh
07322fcd88ecc7a7de38f7b4b5dedbe2f2992b38e12daefb02c52cc4111daab1 aux/wg-add.sh
8cc834717af150b879f9cb9892236fd0fd4695d54bc50fc82a8d31f66a1bfa84 aux/xtables-legacy-multi
60efc5a86f68103c5cf263ba61bdd2a468f93685a947e987f018cac8b95497f2 aux/xtables-nft-multi
454dcddfe5d3ec102c60d7ac363a33e602c803b020acd9602acf5747ac1f77f0 aux/xtables-set-mode.sh
a482389ba330f78b20ef8f46211049ba324efb9c3dfa7f109765b8fb89ec12ae blkid
bf62dd22f4701b05947958a7e4f96ab2c25c64a3d970cf0af3569beccaea33e5 busybox
14af212b8376e7b05205dedafe2914ff053425aa07e1b48eb351d062413d5444 check-config
e603d29f0be3e50bc0bf2123d61ba304e99ceec590f478fc6eb28305769f4ea2 cni
71c4d32d6485966b38b681427974901334a870c6521f9f51e9bc55d782528953 conntrack
21738dafd4a3ecf7cceeba0bb10a4057123f0d6e8e110bc3def23856e382749b containerd
3968d339f99fa5fed7c6ffdb1b65144c9d521541d0049def5c930a38a6b6d526 containerd-shim-runc-v2
65194b284e8c4550db9654d6399b51e156c690a02b7785cf0033e92b159ed6aa coreutils
009b7a87cfbaafb5a415cae29c4ab2780bcff245f66985b4ddbb40cdada92780 ethtool
9bfeec980970df01b9d9553e1cf358284e4771a884209ce1aaf1a3d5b8941c59 find
2345cb11dc35f4b3cd6ea25a1b2bee28f5bdb89fc7d531e7e97c641f2a588c9c fuse-overlayfs
3c89e5664a7801deab2a5f30fea4d42b6ec7b7ce46389d53024d38de1bb8a526 ip
b52d5de7999a5b5b08ecc0bad539f99263b00bc6129aeb7327ead0e8f8b98bcd ipset
030eed517f2ed90bb720b53c9c714ecd193d6135e1246080c22f127b48492d83 k3s
8844aae6c777eda05ec672e46c00508cffefc70672911f108bd890506b77290b losetup
3d4d8a8b835ff29fdf40994690afb428d78e286ff5553452f50dad36345c0de1 nsenter
d7ac92d1df715d2cb5ffa7a8a49b12be738e6e5808e2d8bcadadd799aaad2d8e pigz
a485e12b8509148ea1e29ca423e3cc370cdfa67196c6010a7a293a8cfe338ecc runc
e2759e6c759a5f6977f3e14e2bf4c156cbe8e2914a38143ca3050ddba94a5bb8 slirp4netns
0120777
14346203337
012112
2coreutils
bin/[[
011727
2busybox
bin/addgroup
013167
bin/adduser
013011
bin/ar
011764
bin/arch
012277
bin/arp
012144
bin/arping
012642
bin/ash
012135
bin/aux/
14420104065
010611
bin/aux/arptables
016020
2xtables-nft-multi
bin/aux/arptables-nft
016605
bin/aux/arptables-nft-restore
020266
bin/aux/arptables-nft-save
017541
bin/aux/arptables-restore
017501
bin/aux/arptables-save
016754
bin/aux/ebtables
015624
bin/aux/ebtables-legacy
0100755
00000245470
013604
AWAVAUI
[]A\A]A
[]A\A]
AWAVAUATUH
X[]A\A]A
AWAVAUA
i<-uDA
I9\$8t
ATUSRL
X[]A\A]
{x[]A\
AVAUATU1
9k(vfH
]A\A]A
AVAUATI
H9k8t(H
9k(vNH
AWAVAUATUSH
e0[]A\
G,9G(u
AWAVAUATI
AUATUH
SHcGPH
AWAVAUATU1
D)c$D)e
AVAUATA
u 9_(v*1
AVAUATUSH
([]A\A]A
Z[]A\A]
I9h8uh
E0D9l$p
L$(9L$,t
H9D$xu
AUATUSH
AVAUATUSH9
8[]A\A]A
JhH9(u
E8H9E(t
E8H9E(t 1
AVAUATUH
C8H9C(u+H
w8H9w(
E H+E(L9
u{ATUS
D$[H+D$
\$09\$
D$X[]I
T$ H+T$pH
ttAUATI
Hc{xIc
G8H9G(t
filter
merge wrong
ebtables.c
Ebtables: ebtables.c %s %d :Out of memory.
Spurious characters after '+' wildcard for '%s'
ebtables -t %s -P %s %s
Bridge chain: %s, entries: %d, policy: %s
ebtables -t %s -A %s
Length
--logical-in
--logical-out
Match not found
Watcher not found
standard
Target '%s' not found
-c %lu %lu
, pcnt = %lu -- bcnt = %lu
EBTABLES_ATOMIC_FILE
Multiple commands are not allowed
No chain name specified
Chain %s already exists
Target with name %s exists
Chain name length can't exceed %d
Use of ' ' not allowed in chain names
No extra options allowed with -X
Chain '%s' doesn't exist
No new chain name specified
I was asked the following:
My answer:
yes
Zero indicators is a good indication that something suspect could be a zero day. I don't expect vendors/people to care to dig deeper than the green 0/0 they see when there is no finding. That's a security checkbox that absolves liability – i get it. I dug into the arping binary and this is the map back to MITRE'S ATT&CK framework
Execution TA0002
Command and Scripting Interpreter T1059
Executes the "sed" command used to modify input streams (typically from files or pipes)
Sample contains strings that are potentially command strings
https://attack.mitre.org/techniques/T1059
Scripting T1064
Executes commands using a shell command-line interpreter
https://attack.mitre.org/techniques/T1064
Persistence TA0003
https://attack.mitre.org/tactics/TA0003
Systemd Service T1543.002
Executes the "systemctl" command used for controlling the systemd system and service manager
https://attack.mitre.org/techniques/T1543/002
Privilege Escalation TA0004
https://attack.mitre.org/tactics/TA0004
Systemd Service T1543.002
Executes the "systemctl" command used for controlling the systemd system and service manager
https://attack.mitre.org/techniques/T1543/002/
Defense Evasion TA0005
https://attack.mitre.org/tactics/TA0005/
Scripting T1064
Executes commands using a shell command-line interpreter
https://attack.mitre.org/techniques/T1064/
File Deletion T1070.004
Executes the "rm" command used to delete files or directories
https://attack.mitre.org/techniques/T1070/004
Discovery TA0007
https://attack.mitre.org/tactics/TA0007/
System Information Discovery T1082
Reads system information from the proc file system
Reads CPU information from /sys indicative of miner or evasive malware
https://attack.mitre.org/techniques/T1082
Security Software Discovery T1518.001
Uses the "uname" system call to query kernel version information (possible evasion)
https://attack.mitre.org/techniques/T1518/001
It is possible to use the loopback addresses 169.* or 127.0.0.1 to proxy malicious traffic using something akin to generic routing encapsulation (GRE) and masquerade malicious traffic as local when it is an exfiltration to another host. That bi-directional traffic could control the nodes to remain bots in part of a botnet like Mirai. I am not going to go through the depths the security folks who maintain the software should to lay out why these are indicators worthy of pursuit. I am not getting paid to assist the effort.
arping busybox is a good indicator in combination with the single finding that there could be something to the 224.0.0.0 identified as malicious. Let's dive into ARP
ARP stands for Address Resolution Protocol. It is a network protocol used to map an IP (Internet Protocol) address to a physical MAC (Media Access Control) address in a local area network (LAN).
In a LAN environment, devices communicate with each other using MAC addresses, which are unique identifiers assigned to network interfaces. However, when a device wants to communicate with another device using its IP address, it needs to know the corresponding MAC address to send the data at the data-link layer.
This is where ARP comes into play. When a device wants to send data to another device on the same network, it first checks its ARP cache, which is a table that stores mappings of IP addresses to MAC addresses that the device has recently communicated with. If the MAC address is found in the ARP cache, the device can use that information to send the data directly.
If the IP-to-MAC address mapping is not present in the ARP cache, the device initiates an ARP request. It broadcasts an ARP request message on the LAN, asking the device with the specific IP address to respond with its MAC address. Other devices on the LAN receive this broadcast message, but only the device with the matching IP address responds with its MAC address using an ARP reply message.
Once the requesting device receives the ARP reply message, it updates its ARP cache with the IP-to-MAC address mapping. Now it can use the MAC address to send data directly to the intended device.
ARP operates within the data-link layer of the TCP/IP protocol stack and is used in both IPv4 and IPv6 networks. It is an essential protocol for enabling communication between devices on a local network, allowing them to translate IP addresses to MAC addresses and vice versa.
ARP Poisoning Story Time
Once upon a time, in a bustling local area network (LAN), a group of devices communicated with each other using their unique MAC addresses. Everything seemed harmonious until a mischievous hacker named Eve decided to disrupt the peaceful network.
Eve had a devious plan in mind: to intercept and manipulate the network traffic flowing between the devices. She knew that the Address Resolution Protocol (ARP) was the key to her wicked scheme. ARP was responsible for mapping IP addresses to MAC addresses, ensuring seamless communication within the LAN.
With a sly smile on her face, Eve set her plan into motion. She crafted deceitful ARP messages, containing false IP-to-MAC address mappings. She associated her own MAC address with the IP addresses of unsuspecting devices on the network.
Quietly, Eve sent these forged ARP messages across the LAN, like whispers in the wind. The innocent devices, oblivious to the impending danger, received these messages and unsuspectingly updated their ARP caches with the fake mappings. The devices now believed that Eve's MAC address belonged to legitimate IP addresses on the network.
Unbeknownst to them, chaos was about to unfold. Whenever any of the affected devices wanted to send data to another device using its IP address, it consulted its ARP cache. However, due to Eve's cunning manipulation, the cache contained her MAC address instead of the actual device's MAC address.
The unsuspecting devices, like trusting messengers, sent their valuable network traffic to Eve's machine, believing it to be the true destination. Eve reveled in her newfound power as she intercepted the traffic. She could monitor private conversations, steal sensitive information, or even modify the data before sending it on its way to the intended recipient. Her dark intentions had come to fruition.
To maintain her deceit, Eve diligently forwarded the intercepted traffic to its rightful destination. This way, the devices remained unaware of the treachery at play. Eve's actions went unnoticed, allowing her to continue her malevolent activities undisturbed.
As time went on, the effects of Eve's ARP poisoning attack became increasingly apparent. Communication on the network became unreliable, and some devices experienced frequent disruptions. The once-harmonious LAN was now plagued by confusion and mistrust.
Fortunately, the network administrators were not oblivious to the disturbance. They recognized the signs of ARP poisoning and swiftly took action. They implemented security measures to protect their network. They configured static ARP table entries, ensuring that trusted IP-to-MAC mappings remained untainted by Eve's machinations. Additionally, they deployed intrusion detection systems (IDS) to monitor and detect suspicious ARP activities, sounding the alarm when the mischievous hacker struck again.
Through network segmentation and the implementation of encryption and authentication protocols, the administrators fortified their defenses against Eve's wicked tricks. Gradually, the network regained its stability and trust was restored among the devices.
Eve's reign of ARP poisoning terror had come to an end, thanks to the vigilance and determination of the network administrators. The LAN returned to its harmonious state, with devices once again communicating securely and without the meddling of malicious hackers.
ARP as an indicator
From a threat hunting perspective, ARP poisoning is not specifically employed by the Mirai botnet as its primary attack technique. Instead, Mirai focuses on exploiting vulnerable IoT devices to create a botnet for conducting DDoS attacks. However, it's important to understand the role of ARP scanning within the broader context of threat detection and mitigation.
In the realm of threat hunting, security analysts closely monitor network activities to proactively identify and neutralize potential threats. During this process, ARP scanning can be an essential technique for reconnaissance. By performing ARP scans, analysts can discover active IP addresses and corresponding MAC addresses within a network, gaining visibility into the devices present.
Through diligent analysis of the responses obtained from ARP scans, threat hunters can detect signs of potential compromise or vulnerability within the network. Anomalies such as multiple devices responding with the same MAC address or instances of devices with unexpected IP-to-MAC address associations could indicate suspicious activity or potential ARP poisoning attempts.
While Mirai's primary attack vector lies in exploiting IoT devices with weak security configurations, threat hunters can utilize ARP scanning as an investigative step to identify devices that may have been compromised by the Mirai malware or other similar threats. By monitoring network traffic, examining ARP tables, and correlating findings with other security indicators, threat hunters can discover compromised devices and take appropriate action to mitigate the threat.
By leveraging ARP scanning within the context of threat hunting, security teams can actively search for signs of compromise, identify potential vulnerabilities, and respond swiftly to emerging threats. This proactive approach helps strengthen network defenses and ensures a safer and more secure environment for organizational assets.
The manifest
There is good reason a manifest exists. One indicator in the legitimacy of the original finding is that the platform architecture is arm64
"platform": {
"architecture": "amd64",
"os": "linux"
}
Internet of Things (IoT) devices are typically small and embedded, with many using the ARM architecture. Apple's recent transition to ARM64 in their new M1 and M2 chips has opened up a new avenue for potential security threats. This is because developers who are now working with this architecture could be targeted by those seeking to exploit these new systems. Furthermore, many edge computing devices, such as Raspberry Pi running k3s, also use the ARM64 chipset.
However, the primary concern is not that these devices will be deployed insecurely. The more significant risk lies in the potential for developers using macOS systems with M1 or M2 chips to be unknowingly compromised. This could lead to the continuous theft of sensitive information from the production environment, making the security of the deployment image itself a secondary concern.
To counter these threats, the adoption of DevSecOps practices and architectures is crucial. These practices integrate security into the development process, shifting the responsibility of security to the developers and protecting sensitive information.
As we move forward, we should prepare for more stringent and intrusive methods of identity verification with every digital system we interact with. This is just one example of the challenges we will face in the coming decades as we navigate an increasingly complex digital landscape.