Daily Archives: June 1, 2023

Advisories

USN-6134-1: Linux kernel (Intel IoTG) vulnerabilities

Read Time:4 Minute, 57 Second

It was discovered that the Traffic-Control Index (TCINDEX) implementation
in the Linux kernel did not properly perform filter deactivation in some
situations. A local attacker could possibly use this to gain elevated
privileges. Please note that with the fix for this CVE, kernel support for
the TCINDEX classifier has been removed. (CVE-2023-1829)

It was discovered that the Traffic-Control Index (TCINDEX) implementation
in the Linux kernel contained a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-1281)

It was discovered that the OverlayFS implementation in the Linux kernel did
not properly handle copy up operation in some conditions. A local attacker
could possibly use this to gain elevated privileges. (CVE-2023-0386)

It was discovered that some AMD x86-64 processors with SMT enabled could
speculatively execute instructions using a return address from a sibling
thread. A local attacker could possibly use this to expose sensitive
information. (CVE-2022-27672)

Zheng Wang discovered that the Intel i915 graphics driver in the Linux
kernel did not properly handle certain error conditions, leading to a
double-free. A local attacker could possibly use this to cause a denial of
service (system crash). (CVE-2022-3707)

Haowei Yan discovered that a race condition existed in the Layer 2
Tunneling Protocol (L2TP) implementation in the Linux kernel. A local
attacker could possibly use this to cause a denial of service (system
crash). (CVE-2022-4129)

It was discovered that the network queuing discipline implementation in the
Linux kernel contained a null pointer dereference in some situations. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2022-47929)

It was discovered that the NTFS file system implementation in the Linux
kernel contained a null pointer dereference in some situations. A local
attacker could use this to cause a denial of service (system crash).
(CVE-2022-4842)

Kyle Zeng discovered that the IPv6 implementation in the Linux kernel
contained a NULL pointer dereference vulnerability in certain situations. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2023-0394)

Jordy Zomer and Alexandra Sandulescu discovered that syscalls invoking the
do_prlimit() function in the Linux kernel did not properly handle
speculative execution barriers. A local attacker could use this to expose
sensitive information (kernel memory). (CVE-2023-0458)

Jordy Zomer and Alexandra Sandulescu discovered that the Linux kernel did
not properly implement speculative execution barriers in usercopy functions
in certain situations. A local attacker could use this to expose sensitive
information (kernel memory). (CVE-2023-0459)

It was discovered that the Human Interface Device (HID) support driver in
the Linux kernel contained a type confusion vulnerability in some
situations. A local attacker could use this to cause a denial of service
(system crash). (CVE-2023-1073)

It was discovered that a memory leak existed in the SCTP protocol
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service (memory exhaustion). (CVE-2023-1074)

It was discovered that the TLS subsystem in the Linux kernel contained a
type confusion vulnerability in some situations. A local attacker could use
this to cause a denial of service (system crash) or possibly expose
sensitive information. (CVE-2023-1075)

It was discovered that the Reliable Datagram Sockets (RDS) protocol
implementation in the Linux kernel contained a type confusion vulnerability
in some situations. An attacker could use this to cause a denial of service
(system crash). (CVE-2023-1078)

Xingyuan Mo discovered that the x86 KVM implementation in the Linux kernel
did not properly initialize some data structures. A local attacker could
use this to expose sensitive information (kernel memory). (CVE-2023-1513)

It was discovered that the NFS implementation in the Linux kernel did not
properly handle pending tasks in some situations. A local attacker could
use this to cause a denial of service (system crash) or expose sensitive
information (kernel memory). (CVE-2023-1652)

It was discovered that a race condition existed in the io_uring subsystem
in the Linux kernel, leading to a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-1872)

It was discovered that the Android Binder IPC subsystem in the Linux kernel
did not properly validate inputs in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-20938)

It was discovered that the ARM64 EFI runtime services implementation in the
Linux kernel did not properly manage concurrency calls. A local attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2023-21102)

It was discovered that a use-after-free vulnerability existed in the iSCSI
TCP implementation in the Linux kernel. A local attacker could possibly use
this to cause a denial of service (system crash). (CVE-2023-2162)

Lianhui Tang discovered that the MPLS implementation in the Linux kernel
did not properly handle certain sysctl allocation failure conditions,
leading to a double-free vulnerability. An attacker could use this to cause
a denial of service or possibly execute arbitrary code. (CVE-2023-26545)

It was discovered that the NET/ROM protocol implementation in the Linux
kernel contained a race condition in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-32269)

Duoming Zhou discovered that a race condition existed in the infrared
receiver/transceiver driver in the Linux kernel, leading to a use-after-
free vulnerability. A privileged attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-1118)

Read More

Advisories

USN-6133-1: Linux kernel (Intel IoTG) vulnerabilities

Read Time:2 Minute, 35 Second

It was discovered that the Traffic-Control Index (TCINDEX) implementation
in the Linux kernel did not properly perform filter deactivation in some
situations. A local attacker could possibly use this to gain elevated
privileges. Please note that with the fix for this CVE, kernel support for
the TCINDEX classifier has been removed. (CVE-2023-1829)

It was discovered that some AMD x86-64 processors with SMT enabled could
speculatively execute instructions using a return address from a sibling
thread. A local attacker could possibly use this to expose sensitive
information. (CVE-2022-27672)

Zheng Wang discovered that the Intel i915 graphics driver in the Linux
kernel did not properly handle certain error conditions, leading to a
double-free. A local attacker could possibly use this to cause a denial of
service (system crash). (CVE-2022-3707)

Jordy Zomer and Alexandra Sandulescu discovered that the Linux kernel did
not properly implement speculative execution barriers in usercopy functions
in certain situations. A local attacker could use this to expose sensitive
information (kernel memory). (CVE-2023-0459)

It was discovered that the TLS subsystem in the Linux kernel contained a
type confusion vulnerability in some situations. A local attacker could use
this to cause a denial of service (system crash) or possibly expose
sensitive information. (CVE-2023-1075)

It was discovered that the Reliable Datagram Sockets (RDS) protocol
implementation in the Linux kernel contained a type confusion vulnerability
in some situations. An attacker could use this to cause a denial of service
(system crash). (CVE-2023-1078)

Xingyuan Mo discovered that the x86 KVM implementation in the Linux kernel
did not properly initialize some data structures. A local attacker could
use this to expose sensitive information (kernel memory). (CVE-2023-1513)

It was discovered that a race condition existed in the io_uring subsystem
in the Linux kernel, leading to a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-1872)

It was discovered that the Android Binder IPC subsystem in the Linux kernel
did not properly validate inputs in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-20938)

It was discovered that a use-after-free vulnerability existed in the iSCSI
TCP implementation in the Linux kernel. A local attacker could possibly use
this to cause a denial of service (system crash). (CVE-2023-2162)

It was discovered that the NET/ROM protocol implementation in the Linux
kernel contained a race condition in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-32269)

Duoming Zhou discovered that a race condition existed in the infrared
receiver/transceiver driver in the Linux kernel, leading to a use-after-
free vulnerability. A privileged attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-1118)

Read More

Advisories

USN-6132-1: Linux kernel vulnerabilities

Read Time:2 Minute, 50 Second

Patryk Sondej and Piotr Krysiuk discovered that a race condition existed in
the netfilter subsystem of the Linux kernel when processing batch requests,
leading to a use-after-free vulnerability. A local attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-32233)

Gwangun Jung discovered that the Quick Fair Queueing scheduler
implementation in the Linux kernel contained an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-31436)

Reima Ishii discovered that the nested KVM implementation for Intel x86
processors in the Linux kernel did not properly validate control registers
in certain situations. An attacker in a guest VM could use this to cause a
denial of service (guest crash). (CVE-2023-30456)

It was discovered that the Broadcom FullMAC USB WiFi driver in the Linux
kernel did not properly perform data buffer size validation in some
situations. A physically proximate attacker could use this to craft a
malicious USB device that when inserted, could cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-1380)

Zheng Wang discovered that the Intel i915 graphics driver in the Linux
kernel did not properly handle certain error conditions, leading to a
double-free. A local attacker could possibly use this to cause a denial of
service (system crash). (CVE-2022-3707)

Jordy Zomer and Alexandra Sandulescu discovered that the Linux kernel did
not properly implement speculative execution barriers in usercopy functions
in certain situations. A local attacker could use this to expose sensitive
information (kernel memory). (CVE-2023-0459)

It was discovered that the TLS subsystem in the Linux kernel contained a
type confusion vulnerability in some situations. A local attacker could use
this to cause a denial of service (system crash) or possibly expose
sensitive information. (CVE-2023-1075)

It was discovered that the Reliable Datagram Sockets (RDS) protocol
implementation in the Linux kernel contained a type confusion vulnerability
in some situations. An attacker could use this to cause a denial of service
(system crash). (CVE-2023-1078)

Xingyuan Mo discovered that the x86 KVM implementation in the Linux kernel
did not properly initialize some data structures. A local attacker could
use this to expose sensitive information (kernel memory). (CVE-2023-1513)

It was discovered that a use-after-free vulnerability existed in the iSCSI
TCP implementation in the Linux kernel. A local attacker could possibly use
this to cause a denial of service (system crash). (CVE-2023-2162)

Jean-Baptiste Cayrou discovered that the shiftfs file system in the Ubuntu
Linux kernel contained a race condition when handling inode locking in some
situations. A local attacker could use this to cause a denial of service
(kernel deadlock). (CVE-2023-2612)

It was discovered that the NET/ROM protocol implementation in the Linux
kernel contained a race condition in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-32269)

Duoming Zhou discovered that a race condition existed in the infrared
receiver/transceiver driver in the Linux kernel, leading to a use-after-
free vulnerability. A privileged attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2023-1118)

Read More

Advisories

USN-6131-1: Linux kernel vulnerabilities

Read Time:1 Minute, 12 Second

Patryk Sondej and Piotr Krysiuk discovered that a race condition existed in
the netfilter subsystem of the Linux kernel when processing batch requests,
leading to a use-after-free vulnerability. A local attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-32233)

Gwangun Jung discovered that the Quick Fair Queueing scheduler
implementation in the Linux kernel contained an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-31436)

Reima Ishii discovered that the nested KVM implementation for Intel x86
processors in the Linux kernel did not properly validate control registers
in certain situations. An attacker in a guest VM could use this to cause a
denial of service (guest crash). (CVE-2023-30456)

It was discovered that the Broadcom FullMAC USB WiFi driver in the Linux
kernel did not properly perform data buffer size validation in some
situations. A physically proximate attacker could use this to craft a
malicious USB device that when inserted, could cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-1380)

Jean-Baptiste Cayrou discovered that the shiftfs file system in the Ubuntu
Linux kernel contained a race condition when handling inode locking in some
situations. A local attacker could use this to cause a denial of service
(kernel deadlock). (CVE-2023-2612)

Read More

News

Online Banking – The Safe Way

Read Time:5 Minute, 10 Second

If you’ve got teens, then no doubt you’ve received the SOS texts. ‘Mum, I need a haircut, can you just spot me $30?’ or ‘I’ve just finished footy and I’m starving, can you transfer me some money?’. Where would the modern parent be without online banking? How did our non-digital forefathers ever cope??

Online banking is just so convenient and basically a necessity of modern life. If you’ve recently tried to conduct a transaction at a branch, then you’ll know exactly what I mean. One of my boys recently tried to set up a new account at a local banking branch and they were told to come back the following day. Instead, we went home and did it online in less than 20 minutes!

Aussie banks are world class at implementing a range of security measures to keep our banking safe however there are still things we can do to avoid our banking details getting into the hands of hackers. But many of us just assume that ‘all is well’ – our banking apps work seamlessly, so why do we need to worry? And that’s where many come unstuck. If it doesn’t appear to be broken, why do we need to fix it? Well, being ahead of the risks is how you keep yourself safe, my friends. So, here are my top tips to ensure all your family members are banking online in the securest way possible.

1. Ensure You Are Using Legit Banking Apps

If you’re changing banks or helping your child set up their online banking, it’s essential that you download your bank’s official app. Imitations do exist! Ideally, download the app from the bank’s website however if this isn’t an option use a genuine app store like Apple’s AppStore or Google Play for Android devices. And always verify the app is legitimate by checking the developer details and reading the reviews.

Budgeting or financial management apps are an incredibly popular way to help manage finances, but you need to be cautious here too as many will require you to share your banking logins. Always check the app’s reviews, its history of data breaches and its security policies before you download.

2. Ensure your Passwords are Long, Strong and Unique

Using the name of your puppy, your kids or worse still, your birthday, is one of the fastest ways of getting your banking details into the hands of hackers. Passwords need to have no connection to any part of your life, should never be stored in your banking app or anywhere on your phone and NEVER, EVER written on the back of your debit card!! Here are my top tips:

Make them long – choose a phrase instead of just 1 word. I love a nonsensical sentence with at least 10 characters.

Always include lower and uppercase letters, a number or 2 and a few symbols.

Every online account needs its own unique password – no exceptions.

Put a reminder in your calendar to update your passwords regularly – at least every 3-6 months.

All sounds too hard? Try a password manager that will not only create complex passwords that no human could ever think of, but it will also remember then for you. Check out McAfee +,  complete no brainer!

3. Say No to Public Wi-Fi

Geez, public Wi-Fi is convenient, particularly if you are travelling. But, using it to undertake any banking or financial dealings is just too risky in, my opinion. Why? I hear you ask. Well, there are many ways hackers can hack public Wi-Fi, let me share a few:

‘Evil twin’ attack. This is when hackers set up malicious hotspots with seemingly logical and trustworthy names eg ‘Free Café Wi-Fi’. But as soon as you connect, they can easily get their hands on your data.

Man-in-the-middle attack (MitM). This is when hackers break into a network and eavesdrop on data as it travels between connected devices and the Wi-Fi router. For example, your online banking password!

Password cracking attack. Scammers use software that automatically tries a huge volume of usernames and passwords so they can control the router. And once they’ve gained control, they can dupe you into downloading malicious software (that could steal your identity) or redirects you to a webpage that phishes for your personal information.

If you don’t think you can possibly survive without public Wi-fi then you need to invest in a VPN that will ensure everything you share is protected.

4. Activate Two Factor Authentication

If your bank offers two-factor authentication to its customers, then your answer needs to be ‘yes please’! Two-factor authentication or multi factor authentication adds another layer of verification to your banking which minimises the chances of hacker causing you harm. If you’ve activated it, you’ll be asked to provide another piece of information after you’ve entered your login details. Usually a special code, this may be delivered to you via an app, text message or even an automated phone call.

5. Request Alerts From Your Bank

It will take just a few minutes to ring your bank and request to be notified when an activity occurs on your account. Every bank will manage this differently, however most banks can alert you on request via email or text if the following occur:

Low or high balances
New credit and debit transactions
New linked external accounts
Failed login attempts
Password changes
Personal information updates

And if anything at all seems a little fishy, contact your bank immediately!

Unfortunately, few things are guaranteed in life and that includes your online safety. And whether you’re an online banking fan or not, opting out isn’t really an option. So, take some time to tighten up your online banking. Only use legit apps; change your passwords so they are long, strong and complex; invest in a VPN so you can use public Wi-Fi and say yes to two-factor authentication. You’ve got this!

Happy banking!!

Alex

The post Online Banking – The Safe Way appeared first on McAfee Blog.

Read More

Advisories

USN-6130-1: Linux kernel vulnerabilities

Read Time:59 Second

Patryk Sondej and Piotr Krysiuk discovered that a race condition existed in
the netfilter subsystem of the Linux kernel when processing batch requests,
leading to a use-after-free vulnerability. A local attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-32233)

Gwangun Jung discovered that the Quick Fair Queueing scheduler
implementation in the Linux kernel contained an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-31436)

Reima Ishii discovered that the nested KVM implementation for Intel x86
processors in the Linux kernel did not properly validate control registers
in certain situations. An attacker in a guest VM could use this to cause a
denial of service (guest crash). (CVE-2023-30456)

It was discovered that the Broadcom FullMAC USB WiFi driver in the Linux
kernel did not properly perform data buffer size validation in some
situations. A physically proximate attacker could use this to craft a
malicious USB device that when inserted, could cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-1380)

Read More

News

Ask Fitis, the Bear: Real Crooks Sign Their Malware

Read Time:7 Minute, 1 Second

Code-signing certificates are supposed to help authenticate the identity of software publishers, and provide cryptographic assurance that a signed piece of software has not been altered or tampered with. Both of these qualities make stolen or ill-gotten code-signing certificates attractive to cybercriminal groups, who prize their ability to add stealth and longevity to malicious software. This post is a deep dive on “Megatraffer,” a veteran Russian hacker who has practically cornered the underground market for malware focused code-signing certificates since 2015.

One of Megatraffer’s ads on an English-language cybercrime forum.

A review of Megatraffer’s posts on Russian crime forums shows this user began peddling individual stolen code-signing certs in 2015 on the Russian-language forum Exploit, and soon expanded to selling certificates for cryptographically signing applications and files designed to run in Microsoft Windows, Java, Adobe AIR, Mac and Microsoft Office.

Megatraffer explained that malware purveyors need a certificate because many antivirus products will be far more interested in unsigned software, and because signed files downloaded from the Internet don’t tend to get blocked by security features built into modern web browsers. Additionally, newer versions of Microsoft Windows will complain with a bright yellow or red alert message if users try to install a program that is not signed.

“Why do I need a certificate?” Megatraffer asked rhetorically in their Jan. 2016 sales thread on Exploit. “Antivirus software trusts signed programs more. For some types of software, a digital signature is mandatory.”

At the time, Megatraffer was selling unique code-signing certificates for $700 apiece, and charging more than twice that amount ($1,900) for an “extended validation” or EV code-signing cert, which is supposed to only come with additional identity vetting of the certificate holder. According to Megatraffer, EV certificates were a “must-have” if you wanted to sign malicious software or hardware drivers that would reliably work in newer Windows operating systems.

Part of Megatraffer’s ad. Image: Ke-la.com.

Megatraffer has continued to offer their code-signing services across more than a half-dozen other Russian-language cybercrime forums, mostly in the form of sporadically available EV and non-EV code-signing certificates from major vendors like Thawte and Comodo.

More recently, it appears Megatraffer has been working with ransomware groups to help improve the stealth of their malware. Shortly after Russia invaded Ukraine in February 2022, someone leaked several years of internal chat logs from the Conti ransomware gang, and those logs show Megatraffer was working with the group to help code-sign their malware between July and October 2020.

WHO IS MEGATRAFFER?

According to cyber intelligence firm Intel 471, Megatraffer has been active on more than a half-dozen crime forums from September 2009 to the present day. And on most of these identities, Megatraffer has used the email address 774748@gmail.com. That same email address also is tied to two forum accounts for a user with the handle “O.R.Z.”

Constella Intelligence, a company that tracks exposed databases, finds that 774748@gmail.com was used in connection with just a handful of passwords, but most frequently the password “featar24“. Pivoting off of that password reveals a handful of email addresses, including akafitis@gmail.com.

Intel 471 shows akafitis@gmail.com was used to register another O.R.Z. user account — this one on Verified[.]ru in 2008. Prior to that, akafitis@gmail.com was used as the email address for the account “Fitis,” which was active on Exploit between September 2006 and May 2007. Constella found the password “featar24” also was used in conjunction with the email address spampage@yandex.ru, which is tied to yet another O.R.Z. account on Carder[.]su from 2008.

The email address akafitis@gmail.com was used to create a Livejournal blog profile named Fitis that has a large bear as its avatar. In November 2009, Fitis wrote, “I am the perfect criminal. My fingerprints change beyond recognition every few days. At least my laptop is sure of it.”

Fitis’s Livejournal account. Image: Archive.org.

Fitis’s real-life identity was exposed in 2010 after two of the biggest sponsors of pharmaceutical spam went to war with each other, and large volumes of internal documents, emails and chat records seized from both spam empires were leaked to this author. That protracted and public conflict formed the backdrop of my 2014 book — “Spam Nation: The Inside Story of Organized Cybercrime, from Global Epidemic to Your Front Door.”

One of the leaked documents included a Microsoft Excel spreadsheet containing the real names, addresses, phone numbers, emails, street addresses and WebMoney addresses for dozens of top earners in Spamit — at the time the most successful pharmaceutical spam affiliate program in the Russian hacking scene and one that employed most of the top Russian botmasters.

That document shows Fitis was one of Spamit’s most prolific recruiters, bringing more than 75 affiliates to the Spamit program over several years prior to its implosion in 2010 (and earning commissions on any future sales from all 75 affiliates).

The document also says Fitis got paid using a WebMoney account that was created when its owner presented a valid Russian passport for a Konstantin Evgenievich Fetisov, born Nov. 16, 1982 and residing in Moscow. Russian motor vehicle records show two different vehicles are registered to this person at the same Moscow address.

The most interesting domain name registered to the email address spampage@yahoo.com, fittingly enough, is fitis[.]ru, which DomainTools.com says was registered in 2005 to a Konstantin E. Fetisov from Moscow.

The Wayback Machine at archive.org has a handful of mostly blank pages indexed for fitis[.]ru in its early years, but for a brief period in 2007 it appears this website was inadvertently exposing all of its file directories to the Internet.

One of the exposed files — Glavmed.html — is a general invitation to the infamous Glavmed pharmacy affiliate program, a now-defunct scheme that paid tens of millions of dollars to affiliates who advertised online pill shops mainly by hacking websites and manipulating search engine results. Glavmed was operated by the same Russian cybercriminals who ran the Spamit program.

A Google translated ad circa 2007 recruiting for the pharmacy affiliate program Glavmed, which told interested applicants to contact the ICQ number used by Fitis, a.k.a. MegaTraffer. Image: Archive.org.

Archive.org shows the fitis[.]ru webpage with the Glavmed invitation was continuously updated with new invite codes. In their message to would-be Glavmed affiliates, the program administrator asked applicants to contact them at the ICQ number 165540027, which Intel 471 found was an instant messenger address previously used by Fitis on Exploit.

The exposed files in the archived version of fitis[.]ru include source code for malicious software, lists of compromised websites used for pharmacy spam, and a handful of what are apparently personal files and photos. Among the photos is a 2007 image labeled merely “fitis.jpg,” which shows a bespectacled, bearded young man with a ponytail standing next to what appears to be a newly-married couple at a wedding ceremony.

Mr. Fetisov did not respond to requests for comment.

As a veteran organizer of affiliate programs, Fitis did not waste much time building a new moneymaking collective after Spamit closed up shop. New York City-based cyber intelligence firm Flashpoint found that Megatraffer’s ICQ was the contact number for Himba[.]ru, a cost-per-acquisition (CPA) program launched in 2012 that paid handsomely for completed application forms tied to a variety of financial instruments, including consumer credit cards, insurance policies, and loans.

“Megatraffer’s entrenched presence on cybercrime forums strongly suggests that malicious means are used to source at least a portion of traffic delivered to HIMBA’s advertisers,” Flashpoint observed in a threat report on the actor.

Intel 471 finds that Himba was an active affiliate program until around May 2019, when it stopping paying its associates.

Fitis’s Himba affiliate program, circa February 2014. Image: Archive.org.

Flashpoint notes that in September 2015, Megatraffer posted a job ad on Exploit seeking experienced coders to work on browser plugins, installers and “loaders” — basically remote access trojans (RATs) that establish communication between the attacker and a compromised system.

“The actor specified that he is looking for full-time, onsite help either in his Moscow or Kiev locations,” Flashpoint wrote.

Read More