Capturing DShield Packets with a LAN Tap [Guest Diary], (Sun, Mar 3rd)

This post was originally published on this site

[This is a Guest Diary by Christopher Von Reybyton, an ISC intern as part of the SANS.edu BACS program]

Introduction

During my internship with the Internet Storm Center I ran into an issue of wanting more information than the default logs would give me. I recalled one of the instructors saying "If we don’t have packets it didn’t happen". This inspired me to try to capture the packets hitting my honeypot. Initially I looked for ways to add logging capabilities to the DShield Honeypot [1]. I found very little information and the information I found I wasn’t able to get to work. Then I remembered that I owned a Great Scott Gadgets Throwing Star LAN Tap [2]. The Throwing Star LAN Tap is a passive Ethernet tap set between my router and the honeypot where I capture .pcap files with Wireshark.

Throwing Star LAN Tap

The Throwing Star LAN Tap can be purchased from greatscottgadgets.com and amazon.com. It has two pass-through ethernet adapters labeled J1 and J2. This allows the LAN Tap to sit between the router and an end device. There are two other ethernet adapters labeled J3 and J4. These adapters have capacitors connected to them and any packets are output to these monitoring ports. By connecting a device to these monitoring ports we are able to capture packets with apps such as Wireshark or tcpdump.
The following image is how the LAN Tap arrives unassembled.

Next is how the LAN Tap looks when assembled. Notice the placement of the capacitors.

Here is an image of the back of the LAN Tap after soldering.

Lastly here is a graphic showing the direction the packets travel to the monitoring ports.

Analysis

An example of how the packet information from Wireshark helps in attack observations can be found in the following screenshots.
First is output from the honeypot using the command "cat webhoneypot-2024-01-25.json | jq 'select(.sip == "80.94.95.226")'". This image shows output with a timestamp of 23:43:18. The attacker is trying to POST information to "/cgi-bin/luci"

The next screenshot shows the output from Wireshark using the filter "http.request.method == "GET" || http.request.method == "POST".  At No. 5181 and timestamp 23:43:17 we see the POST request from IP 80.94.95.226

If we then follow the HTTP Stream of this conversation, we end up with the next screenshot. If you look at the end of the output, you will see the username and password used by the threat actor. This is information that is absent in the DShield logs and gives added insight into the attackers’ behavior.

Identified problems

The main problem I ran into was that my Throwing Star LAN Tap was a kit. I had to solder the Ethernet connectors and diodes to the circuit board. As I don’t have a lot of experience with this it took some trial and error to make sure the connections were soldered on correctly. My first attempt after soldering seemed to have worked as I was able to receive packets for many hours. The next day that I connected I only captured packets that came from the honeypot. I had to disconnect the LAN Tap and go over the connections again to make sure the soldering was correct. The third attempt resulted in capturing full packets.

It should be noted that the reason I only captured packets coming from the honeypot on the second day is that since the Dshield honeypot resets every day the LAN Tap needs to be re-connected everyday as well. And that the monitoring ports only monitor traffic in one direction.

Why It Matters

Packets are how everything is communicated through networks. It doesn’t matter what protocol is used or where the device is located. And while collecting logs is important, being able to see the history of the logs communication in the form of packets is the basis for good information security. Information that may be passed in clear text in the packets may not be picked up by DSHield logs.

Benefits

The main benefit of capturing packets is that you have visibility into the communication going to and from the DShield honeypot. It’s nice seeing the SSH and HTTP logs that DShield collects, but being able to go through the packets gives a much deeper insight into what attacks are happening and how they are happening. For me parsing logs felt like only seeing part of the conversation. Being able to see the packets now makes parsing the logs more complete and easier to interpret. 

Conclusion

Capturing packets between the DShield honeypot and an externally facing router is a powerful tool to help with attack observations and identifying threat actors’ behavior for accurate documentation. In the future I would love to see packet capture capabilities added to the DShield, but until then using a LAN Tap can give us vital information to increase the scope of our attack documentation.

[1] https://isc.sans.edu/tools/honeypot/
[2] https://greatscottgadgets.com/throwingstar/
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Scanning for Confluence CVE-2022-26134, (Fri, Mar 1st)

This post was originally published on this site

I have added daemonlogger [1] for packet capture and Arkime [2] to visualize the packets captured by my DShield sensor and started noticing this activity that so far only gone to TCP/8090 which is URL and base64 encoded. The DShield sensor started capturing this activity on the 12 February 2024 inbound from various IPs from various locations.

Takes Downs and the Rest of Us: Do they matter?, (Tue, Feb 27th)

This post was originally published on this site

Last week, the US Department of Justice published a press release entitled "Justice Department Conducts Court-Authorized Disruption of Botnet Controlled by the Russian Federation’s Main Intelligence Directorate of the General Staff (GRU)" [1]. The disruption targeted a botnet built using the "Moobot" malware. According to the press release, this particular botnet focused on routers made by Ubiquity, using well-known default credentials. 

AWS Weekly Roundup — .Net Runtime for AWS Lambda, PartyRock Hackathon, and more — February 26, 2024

This post was originally published on this site

The Community AWS re:invent 2023 re:caps continue! Recently, I was invited to participate in one of these events hosted by the AWS User Group Kenya, and was able to learn and spend time with this amazing community.

AWS User Group Kenya

AWS User Group Kenya

Last week’s launches
Here are some launches that got my attention during the previous week.

.NET 8 runtime for AWS Lambda – AWS Lambda now supports .NET 8 as both a managed runtime and container base image. This support provides you with .NET 8 features that include API enhancements, improved Native Ahead of Time (Native AOT) support, and improved performance. .NET 8 supports C# 12, F# 8, and PowerShell 7.4. You can develop Lambda functions in .NET 8 using the AWS Toolkit for Visual Studio, the AWS Extensions for .NET CLI, AWS Serverless Application Model (AWS SAM), AWS CDK, and other infrastructure as code tools.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Other AWS news
Here are some additional projects, programs, and news items that you might find interesting:

Earlier this month, I used this image to call attention to the PartyRock Hackathon that’s currently in progress. The deadline to join the hackathon is fast approaching so be sure to signup before time runs out.

Amazon API Gateway – Amazon API Gateway processed over 100 trillion API requests in 2023, and we continue to see growing demand for API-driven applications. API Gateway is a fully-managed service that enables you to create, publish, maintain, monitor, and secure APIs at any scale. Customers that onboarded large workloads on API Gateway in 2023 told us they chose the service for its availability, security, and serverless architecture. Those in regulated industries value API Gateway’s private endpoints, which are isolated from the public internet and only accessible from your Amazon Virtual Private Cloud (VPC).

AWS open source news and updates – My colleague Ricardo writes this weekly open source newsletter in which he highlights new open source projects, tools, and demos from the AWS Community.

Upcoming AWS events
Season 3 of the Build on Generative AI Twitch show has kicked off. Join every Monday on Twitch at 9AM PST/Noon EST/18h CET to learn among others, how you can build generative AI-enabled applications.

If you’re in the EMEA timezone, there is still time to register and watch the AWS Innovate Online Generative AI & Data Edition taking place on February 29. Innovate Online events are free, online, and designed to inspire and educate you about building on AWS. Whether you’re in the Americas, Asia Pacific & Japan, or EMEA region, learn here about future AWS Innovate Online events happening in your timezone.

AWS Community re:Invent re:Caps – Join a Community re:Cap event organized by volunteers from AWS User Groups and AWS Cloud Clubs around the world to learn about the latest announcements from AWS re:Invent.

You can browse all upcoming in-person and virtual events here.

That’s all for this week. Check back next Monday for another Weekly Roundup!

Veliswa

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS.

New AWS Region in Mexico is in the works

This post was originally published on this site

Today, I am happy to announce that we are working on an AWS Region in Mexico. This AWS Mexico (Central) Region will be the second Region in Latin America joining the AWS South America (São Paulo) Region and will give AWS customers the ability to run workloads and store data that must remain in-country.

Mexico in the works

The Region will include three Availability Zones, each one physically independent of the others in the Region yet far enough apart to minimize the risk that an event in one Availability Zone will have impact on business continuity. The Availability Zones will be connected to each other by high-bandwidth, low-latency network connections over dedicated, fully redundant fiber.

With this announcement, AWS now has five new Regions in the works (Germany, Malaysia, Mexico, New Zealand, and Thailand) and 15 upcoming new Availability Zones.

AWS investment in Mexico

The upcoming AWS Mexico Region is the latest in ongoing investments by AWS in Mexico to provide customers with advanced and secure cloud technologies. Since 2020, AWS has launched seven Amazon CloudFront edge locations in Mexico. Amazon CloudFront is a highly secure and programmable content delivery network (CDN) that accelerates the delivery of data, videos, applications, and APIs to users worldwide with low latency and high transfer speeds.

In 2020, AWS launched AWS Outposts in Mexico. AWS Outposts is a family of fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience. AWS expanded its infrastructure footprint in Mexico again in 2023 with the launch of AWS Local Zones in Queretaro. AWS Local Zones are a type of AWS infrastructure deployment that places compute, storage, database, and other select services closer to large population, industry, and IT centers, enabling customers to deliver applications that require single-digit millisecond latency to end users. In 2023, AWS established an AWS Direct Connect location in Queretaro, allowing customers to establish private connectivity between AWS and their data center, office, or colocation environment.

Here is a glimpse into our customers in Mexico and the exciting, innovative work they’re undertaking:

Banco Santander Mexico is one of the leading financial groups in the country, focused on commercial banking and securities financing, serving more than 20.5 million customers. “AWS has been a strategic partner for our digital transformation,” said Juan Pablo Chiappari, head of IT Infrastructure for North America. “Thanks to their wide range of services, we have been able to innovate faster, improve our customer experience and reduce our operating costs.”

SkyAlert is an innovative technology company that quickly alerts millions of people living in earthquake-prone areas, promoting a culture of prevention against natural disasters. In order to provide customers—both businesses and individuals—with the right tools to protect themselves during earthquakes, SkyAlert migrated its infrastructure to AWS. After implementing its Internet of Things (IoT) solution to run on AWS and its efficient alert service, SkyAlert scales quickly and can send millions of messages in a few seconds, helping to save lives in the event of earthquakes.

Kueski is an online lender for the middle class of Mexico and Latin America. The company uses big data and advanced analytics to approve and deliver loans in a matter of minutes. The company has become the fastest-growing platform of its kind in the region and has already granted thousands of loans. They were born with AWS.

Bolsa Institucional de Valores (BIVA) is a stock exchange based in Mexico, backed by Nasdaq. BIVA provides local and global investors with cutting-edge technology for trading and market solutions and companies with listing and maintenance services. As part of its vision of innovation, BIVA started its journey to the cloud in 2023 by migrating its disaster recovery site, including its trading and market surveillance systems, to AWS, using edge compute capabilities available in both the AWS Local Zones in Queretaro, Mexico, to achieve their low latency needs.

Stay Tuned
The AWS Region in Mexico will open in early 2025. As usual, subscribe to this blog so that you will be among the first to know when the new Region is open!

To learn more about AWS Global Cloud Infrastructure, see the Global Infrastructure page.

— Irshad

#StopRansomware: Phobos Ransomware

This post was originally published on this site

SUMMARY

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint CSA, to disseminate known TTPs and IOCs associated with the Phobos ransomware variants observed as recently as February 2024, according to open source reporting. Phobos is structured as a ransomware-as-a-service (RaaS) model. Since May 2019, Phobos ransomware incidents impacting state, local, tribal, and territorial (SLTT) governments have been regularly reported to the MS-ISAC. These incidents targeted municipal and county governments, emergency services, education, public healthcare, and other critical infrastructure entities to successfully ransom several million U.S. dollars.[1],[2]

The FBI, CISA, and the MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of Phobos ransomware and other ransomware incidents.

Download the PDF version of this report:

For a downloadable copy of indicators of compromise (IOCs), see:

AA24-060A STIX XML
(XML, 147.73 KB
)
AA24-060A STIX JSON
(JSON, 119.53 KB
)

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 14. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Overview

According to open source reporting, Phobos ransomware is likely connected to numerous variants (including Elking, Eight, Devos, Backmydata, and Faust ransomware) due to similar TTPs observed in Phobos intrusions. Phobos ransomware operates in conjunction with various open source tools such as Smokeloader, Cobalt Strike, and Bloodhound. These tools are all widely accessible and easy to use in various operating environments, making it (and associated variants) a popular choice for many threat actors.[3],[4]

Reconnaissance and Initial Access

Phobos actors typically gain initial access to vulnerable networks by leveraging phishing campaigns [T1598] to drop hidden payloads or using internet protocol (IP) scanning tools, such as Angry IP Scanner, to search for vulnerable Remote Desktop Protocol (RDP) ports [T1595.001] or by leveraging RDP on Microsoft Windows environments.[5],[6]

Once they discover an exposed RDP service, the actors use open source brute force tools to gain access [T1110]. If Phobos actors gain successful RDP authentication [T1133][T1078] in the targeted environment, they perform open source research to create a victim profile and connect the targeted IP addresses to their associated companies [T1593]. Threat actors leveraging Phobos have notably deployed remote access tools to establish a remote connection within the compromised network [T1219].[7]

Alternatively, threat actors send spoofed email attachments [T1566.001] that are embedded with hidden payloads [T1204.002] such as SmokeLoader, a backdoor trojan that is often used in conjunction with Phobos. After SmokeLoader’s hidden payload is downloaded onto the victim’s system, threat actors use the malware’s functionality to download the Phobos payload and exfiltrate data from the compromised system.

Execution and Privilege Escalation

Phobos actors run executables like 1saas.exe or cmd.exe to deploy additional Phobos payloads that have elevated privileges enabled [TA0004]. Additionally, Phobos actors can use the previous commands to perform various windows shell functions. The Windows command shell enables threat actors to control various aspects of a system, with multiple permission levels required for different subsets of commands [T1059.003][T1105].[8]

Smokeloader Deployment

Phobos operations feature a standard three phase process to decrypt a payload that allows the threat actors to deploy additional destructive malware.[9]

For the first phase, Smokeloader manipulates either VirtualAlloc or VirtualProtect API functions—which opens an entry point, enabling code to be injected into running processes and allowing the malware to evade network defense tools [T1055.002]. In the second phase, a stealth process is used to obfuscate command and control (C2) activity by producing requests to legitimate websites [T1001.003].[10]

Within this phase, the shellcode also sends a call from the entry point to a memory container [T1055.004] and prepares a portable executable for deployment in the final stage [T1027.002][T1105][T1140].

Finally, once Smokeloader reaches its third stage, it unpacks a program-erase cycle from stored memory, which is then sent to be extracted from a SHA 256 hash as a payload.[7] Following successful payload decryption, the threat actors can begin downloading additional malware.

Additional Phobos Defense Evasion Capabilities

Phobos ransomware actors have been observed bypassing organizational network defense protocols by modifying system firewall configurations using commands like netsh firewall set opmode mode=disable [T1562.004]. Additionally, Phobos actors can evade detection by using the following tools: Universal Virus Sniffer, Process Hacker, and PowerTool [T1562].

Persistence and Privilege Escalation

According to open source reporting, Phobos ransomware uses commands such as Exec.exe or the bcdedit[.]exe control mechanism. Phobos has also been observed using Windows Startup folders and Run Registry Keys such as C:/UsersAdminAppDataLocaldirectory [T1490][T1547.001] to maintain persistence within compromised environments.[5]

Additionally, Phobos actors have been observed using built-in Windows API functions [T1106] to steal tokens [T1134.001], bypass access controls, and create new processes to escalate privileges by leveraging the SeDebugPrivilege process [T1134.002]. Phobos actors attempt to authenticate using cached password hashes on victim machines until they reach domain administrator access [T1003.005].

Discovery and Credential Access

Phobos actors additionally use open source tools [T1588.002] such as Bloodhound and Sharphound to enumerate the active directory [T1087.002]. Mimikatz and NirSoft, as well as Remote Desktop Passview to export browser client credentials [T1003.001][T1555.003], have also been used. Furthermore, Phobos ransomware is able to enumerate connected storage devices [T1082], running processes [T1057], and encrypt user files [T1083].

Exfiltration

Phobos actors have been observed using WinSCP and Mega.io for file exfiltration.[11] They use WinSCP to connect directly from a victim network to an FTP server [T1071.002] they control [TA0010]. Phobos actors install Mega.io [T1048] and use it to export victim files directly to a cloud storage provider [T1567.002]. Data is typically archived as either a .rar or .zip file [T1560] to be later exfiltrated. They target legal documentation, financial records, technical documents (including network architecture), and databases for commonly used password management software [T1555.005].

Impact

After the exfiltration phase, Phobos actors then hunt for backups. They use vssadmin.exe and Windows Management Instrumentation command-line utility (WMIC) to discover and delete volume shadow copies in Windows environments. This prevents victims from recovering files after encryption has taken place [T1047][T1490].

Phobos.exe contains functionality to encrypt all connected logical drives on the target host [T1486]. Each Phobos ransomware executable has unique build identifiers (IDs), affiliate IDs, as well as a unique ransom note which is embedded in the executable. After the ransom note has populated on infected workstations, Phobos ransomware continues to search for and encrypt additional files.

Most extortion [T1657] occurs via email; however, some affiliate groups have used voice calls to contact victims. In some cases, Phobos actors have used onion sites to list victims and host stolen victim data. Phobos actors use various instant messaging applications such as ICQ, Jabber, and QQ to communicate [T1585]. See Figure 2 for a list of email providers used by the following Phobos affiliates: Devos, Eight, Elbie, Eking, and Faust.[6]

Figure 1: Phobos Affiliate Providers List

Figure 1: Phobos Affiliate Providers List

INDICATORS OF COMPROMISE (IOCs)

See Table 1 through 6 for IOCs obtained from CISA and the FBI investigations from September through November 2023.

Table 1: Associated Phobos Domains
Associated Phobos Domains

adstat477d[.]xyz

demstat577d[.]xyz [12]

serverxlogs21[.]xyz

Table 2: Observed Phobos Shell Commands
Shell Commands

vssadmin delete shadows /all /quiet [T1490]

netsh advfirewall set currentprofile state off

wmic shadowcopy delete

netsh firewall set opmode mode=disable [T1562.004]

bcdedit /set {default} bootstatuspolicy ignoreallfailures [T1547.001]

bcdedit /set {default} recoveryenabled no [T1490]

wbadmin delete catalog -quiet

mshta C:%USERPROFILE%Desktopinfo.hta [T1218.005]

mshta C:%PUBLIC%Desktopinfo.hta

mshta C:info.hta

The commands above are observed during the execution of a Phobos encryption executable. A Phobos encryption executable spawns a cmd.exe process, which then executes the commands listed in Table 1 with their respective Windows system executables. When the commands above are executed on a Windows system, volume shadow copies are deleted and Windows Firewall is disabled. Additionally, the system’s boot status policy is set to boot even when there are errors during the boot process, and automatic recovery options, like Windows Recovery Environment (WinRE), are disabled for the given boot entry. The system’s backup catalog is also deleted. Finally, the Phobos ransom note is displayed to the end user using mshta.exe.

Table 3: Observed Phobos Registry Keys
Registry Keys

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun<Phobos exe name>

C:/UsersAdminAppDataLocaldirectory

Table 4: Observed Phobos Actor Email Addresses
Email Addresses  

AlbetPattisson1981@protonmail[.]com

henryk@onionmail[.]org

atomicday@tuta[.]io

info@fobos[.]one

axdus@tuta[.]io

it.issues.solving@outlook[.]com

barenuckles@tutanota[.]com

JohnWilliams1887@gmx[.]com

Bernard.bunyan@aol[.]com

jonson_eight@gmx[.]us

bill.g@gmx[.]com

joshuabernandead@gmx[.]com

bill.g@msgsafe[.]io

LettoIntago@onionmail[.]com

bill.g@onionmail[.]org

Luiza.li@tutanota[.]com

bill.gTeam@gmx[.]com

MatheusCosta0194@gmx[.]com

blair_lockyer@aol[.]com

mccreight.ellery@tutanota[.]com

CarlJohnson1948@gmx[.]com

megaport@tuta[.]io

cashonlycash@gmx[.]com

miadowson@tuta[.]io

chocolate_muffin@tutanota[.]com

MichaelWayne1973@tutanota[.]com

claredrinkall@aol[.]com

normanbaker1929@gmx[.]com

clausmeyer070@cock[.]li

nud_satanakia@keemail[.]me

colexpro@keemail[.]me

please@countermail[.]com

cox.barthel@aol[.]com

precorpman@onionmail[.]org

crashonlycash@gmx[.]com

recovery2021@inboxhub[.]net

everymoment@tuta[.]io

recovery2021@onionmail[.]org

expertbox@tuta[.]io

SamuelWhite1821@tutanota[.]com

fastway@tuta[.]io

SaraConor@gmx[.]com

fquatela@techie[.]com

secdatltd@gmx[.]com

fredmoneco@tutanota[.]com

skymix@tuta[.]io

getdata@gmx[.]com

sory@countermail[.]com

greenbookBTC@gmx[.]com

spacegroup@tuta[.]io

greenbookBTC@protonmail[.]com

stafordpalin@protonmail[.]com

helperfiles@gmx[.]com

starcomp@keemail[.]me

helpermail@onionmail[.]org

xdone@tutamail[.]com

helpfiles@onionmail[.]org

xgen@tuta[.]io

helpfiles102030@inboxhub[.]net

xspacegroup@protonmail[.]com

helpforyou@gmx[.]com

zgen@tuta[.]io

helpforyou@onionmail[.]org

zodiacx@tuta[.]io

Table 5: Observed Phobos Actor Telegram Username
Telegram Username

@phobos_support

Table 6: Observed Phobos Actor Wickr Address
Wickr Address
  • Vickre me

Disclaimer: Organizations are encouraged to investigate the use of the IOCs in Table 7 for related signs of compromise prior to performing remediation actions.

Table 7: Phobos IOCs from September through December 2023
Associated IP Address File Type File Name SHA 256 Hash

194.165.16[.]4 (October 2023)

Win32.exe

Ahpdate.exe [13]

0000599cbc6e5b0633c5a6261c79e4d3d81005c77845c6b0679d854884a8e02f

45.9.74[.]14 (December 2023)

147.78.47[.]224 (December 2023)

Executable and Linkable Format (ELF) [14]

1570442295

(Trojan Linux Mirai)

7451be9b65b956ee667081e1141531514b1ec348e7081b5a9cd1308a98eec8f0

185.202.0[.]111 (September 2023)

Win32.exe [15]

cobaltstrike_shellcode[.]exe (C2 activity)

 

185.202.0[.]111 (December 2023)

.txt [16]

f1425cff3d28afe5245459afa6d7985081bc6a62f86dce64c63daeb2136d7d2c.bin (Trojan)

Disclaimer: Organizations are encouraged to investigate the use of the file hashes in Tables 8 and 9 for related signs of compromise prior to performing remediation actions.

Table 8: Phobos Actor File Hashes Observed in October 2023
Phobos Ransomware SHA 256 Malicious Trojan Executable File Hashes

518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c

9215550ce3b164972413a329ab697012e909d543e8ac05d9901095016dd3fc6c

482754d66d01aa3579f007c2b3c3d0591865eb60ba60b9c28c66fe6f4ac53c52

c0539fd02ca0184925a932a9e926c681dc9c81b5de4624250f2dd885ca5c4763

Table 9: Phobos Actor File Hashes from Open Source from November 2023 [17]
Phobos Ransomware SHA 256 File Hashes

58626a9bfb48cd30acd0d95debcaefd188ae794e1e0072c5bde8adae9bccafa6

f3be35f8b8301e39dd3dffc9325553516a085c12dc15494a5e2fce73c77069ed

518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c

32a674b59c3f9a45efde48368b4de7e0e76c19e06b2f18afb6638d1a080b2eb3

2704e269fb5cf9a02070a0ea07d82dc9d87f2cb95e60cb71d6c6d38b01869f66

fc4b14250db7f66107820ecc56026e6be3e8e0eb2d428719156cf1c53ae139c6

a91491f45b851a07f91ba5a200967921bf796d38677786de51a4a8fe5ddeafd2

MITRE ATT&CK TECHNIQUES

See Table 10 through 22 for all threat actor tactics and techniques referenced in this advisory.

Table 10: Phobos Threat Actors ATT&CK Techniques for Enterprise – Reconnaissance
Technique Title ID Use

Search Open Websites/Domains

T1593

Phobos actors perform open source research to find information about victims that can be used during targeting to create a victim profile.

Scanning IP Blocks

T1595.001

Phobos actors used IP scanning tools to include Angry IP Scanner to search for vulnerable RDP ports.

Phishing for Information

T1598

Phobos actors use phishing campaigns to social engineer information from users and gain access to vulnerable RDP ports.

Table 11: Phobos Threat Actors ATT&CK Techniques for Enterprise – Resource Development
Technique Title ID Use

Establish Accounts

T1585

Phobos actors establish accounts to communicate.

Obtain Capabilities: Tool

T1588.002

Phobos actors used open source tools in their attack.

Table 12: Phobos Threat Actors ATT&CK Techniques for Enterprise – Initial Access
Technique Title ID Use

Valid Accounts

T1078

Following successful RDP authentication, Phobos actors search for IP addresses and pair them with their associated computer to create a victim profile.

External Remote Services

T1133

Phobos actors may leverage external-facing remote services to initially access and/or persist within a network.

Phishing: Spearphishing Attachment

T1566.001

Phobos actors used a spoofed email attachment to execute attack.

Table 13: Phobos Threat Actors ATT&CK Techniques for Enterprise – Execution
Technique Title ID Use

Windows Management Instrumentation

T1047

Phobos actors used Windows Management Instrumentation command-line utility (WMIC) to prevent victims from recovering files.

Windows Command Shell

T1059.003

Phobos actors can use the previous commands to perform commands with windows shell functions.

Native API

T1106

Phobos actors used open source tools to enumerate the active directory.

Malicious File

T1204.002

Phobos actors attached a malicious email attachment to deliver ransomware.

Table 14: Phobos Threat Actors ATT&CK Techniques for Enterprise – Persistence
Technique Title ID Use

Registry Run Keys / Startup Folder

T1547.001

Phobos ransomware operates using the Exec.exe control mechanism and has been observed using Windows Startup folders and Run Registry Keys.

Table 15: Phobos Threat Actors ATT&CK Techniques for Enterprise – Privilege Escalation
Technique Title ID Use

Privilege Escalation

TA0004

Phobos actors use run commands like 1saas.exe, or cmd.exe to deploy additional Phobos payloads with escalated privileges.

Portable Executable Injection

T1055.002

Phobos actors use Smokeloader to inject code into running processes to identify an entry point through enabling a VirtualAlloc or VirtualProtect process.

Asynchronous Procedure Call

T1055.004

During phase two of execution, Phobos ransomware sends a call back from an identified entry point.

Access Token Manipulation: Token Impersonation/Theft

T1134.001

Phobos actors can use Windows API functions to steal tokens.

Create Process with Token

T1134.002

Phobos actors used Windows API functions to steal tokens, bypass access controls and create new processes.

Table 16: Phobos Threat Actors ATT&CK Techniques for Enterprise – Defense Evasion
Technique Title ID Use

Software Packing

T1027.002

Phobos actors deployed a portable executable (PE) to conceal code.

Embedded Payloads

T1027.009

Phobos actors embedded the ransomware as a hidden payload by using Smokeloader.

Deobfuscate/Decode Files or Information

T1140

During phase two of execution, Phobos actors’ malware stores and decrypts information.

System Binary Proxy Execution: Mshta

T1218.005

Phobos actors used Mshta to execute malicious files.

Impair Defenses

T1562

Phobos actors can use Universal Virus Sniffer, Process Hacker, and PowerTool to evade detection.

Disable or Modify System Firewall

T1562.004

Phobos ransomware has been observed bypassing organizational network defense protocols through modifying system firewall configurations.

Table 17: Phobos Threat Actors ATT&CK Techniques for Enterprise – Credential Access
Technique Title ID Use

OS Credential Dumping: LSASS Memory

T1003.001

Phobos actors used Mimikatz to export credentials.

OS Credential Dumping: Cached Domain Credentials

T1003.005

Phobos actors use cached domain credentials to authenticate as the domain administrator in the event a domain controller is unavailable.

Brute Force

T1110

Phobos actors may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.

Credentials from Password Stores

T1555

Phobos actors may search for common password storage locations to obtain user credentials.

Credentials from Password Stores: Credentials from Web Browsers

T1555.003

Phobos actors use Nirsoft or Passview to export client credentials from web browsers.

Phobos actors search for stored credentials in browser clients once they gain initial network access.

Credentials from Password Stores: Password Managers

T1555.005

Phobos actors targeted victim’s databases for password management software.

Table 18: Phobos Threat Actors ATT&CK Techniques for Enterprise – Discovery
Technique Title ID Use

Process Discovery

T1057

Phobos ransomware is able to run processes.

System Information Discovery

T1082

Phobos ransomware is able to enumerate connected storage devices.

File and Directory Discovery

T1083

Phobos ransomware can encrypt user files.

Domain Account

T1087.002

Phobos threat actor used Bloodhound and Sharphound to enumerate the active directory.

Table 19: Phobos Threat Actors ATT&CK Techniques for Enterprise – Collection
Technique Title ID Use

Archive Collected Data

T1560

Phobos threat actors archive data as either a .rar or .zip file to be later exfiltrated.

Table 20: Phobos Threat Actors ATT&CK Techniques for Enterprise – Command and Control
Technique Title ID Use

Data Obfuscation: Protocol Impersonation

T1001.003

Phobos actors used a stealth process to obfuscate C2 activity.

File Transfer Protocols

T1071.002

Phobos threat actors used WinSCP to connect the victim’s network to an FTP server.

Ingress Tool Transfer

T1105

Phobos ransomware extracts its final payload from the hashed file.

Remote Access Software

T1219

Phobos threat actors used remote access tools to establish a remote connection within victim’s network.

Table 21: Phobos Threat Actors ATT&CK Techniques for Enterprise – Exfiltration
Technique Title ID Use

Exfiltration

TA0010

Phobos threat actors may use exfiltration techniques to steal data from your network.

Exfiltration Over Alternative Protocol

T1048

Phobos threat actors use software to export files to a cloud.

Exfiltration to Cloud Storage

T1567.002

Phobos threat actors use Mega.io to exfiltrate data to a cloud storage service rather than over their primary command and control channel.

Table 22: Phobos Threat Actors ATT&CK Techniques for Enterprise – Impact
Technique Title ID Use

Data Encrypted for Impact

T1486

Phobos threat actors use the Phobos.exe command to encrypt data on all logical drives connected to the network.

Inhibit System Recovery

T1490

Phobos threat actors may delete or remove backups to include volume shadow copies from Windows environments to prevent victim data recovery response efforts.

Financial Theft

T1657

Phobos threat actor’s extort victims for financial gain.

MITIGATIONS

Secure by Design and Default Mitigations:

These mitigations apply to all critical infrastructure organizations and network defenders. The FBI, CISA, and MS-ISAC recommend that software manufacturers incorporate secure by design and default principles and tactics into their software development practices limiting the impact of ransomware techniques, thus, strengthening the secure posture for their customers.

For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

The FBI, CISA, and MS-ISAC recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture against actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

  • Secure remote access software by applying recommendations from the joint Guide to Securing Remote Access Software.
  • Implement application controls to manage and control execution of software, including allowlisting remote access programs.
    • Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlist solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
  • Implement log collection best practices and use intrusion detection systems to defend against threat actors manipulating firewall configurations through early detection [CPG 2.T].
    • Implement EDR solutions to disrupt threat actor memory allocation techniques.
  • Strictly limit the use of RDP and other remote desktop services. If RDP is necessary, rigorously apply best practices, for example [CPG 2.W]:
  • Disable command-line and scripting activities and permissions [CPG 2.N].
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 4.C].
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege (PoLP) [CPG 2.E].
  • Reduce the threat of credential compromise via the following:
    • Place domain admin accounts in the protected users’ group to prevent caching of password hashes locally.
    • Refrain from storing plaintext credentials in scripts.
  • Implement time-based access for accounts at the admin level and higher [CPG 2.A, 2.E].

In addition, the authoring authorities of this CSA recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, and to reduce the impact and risk of compromise by ransomware or data extortion actors:

  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, or the cloud).
  • Maintain offline backups of data and regularly maintain backup and restoration (daily or weekly at minimum). By instituting this practice, an organization limits the severity of disruption to its business practices [CPG 2.R].
  • Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with NIST’s standards for developing and managing password policies.
    • Use longer passwords consisting of at least 15 characters and no more than 64 characters in length [CPG 2.B].
    • Store passwords in hashed format using industry-recognized password managers.
    • Add password user “salts” to shared login credentials.
    • Avoid reusing passwords [CPG 2.C].
    • Implement multiple failed login attempt account lockouts [CPG 2.G].
    • Disable password “hints.”
    • Refrain from requiring password changes more frequently than once per year.
      Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
    • Require administrator credentials to install software.
  • Require phishing-resistant multifactor authentication (MFA) for all services to the extent possible, particularly for webmail, virtual private networks (VPNs), and accounts that access critical systems [CPG 2.H].
  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement [CPG 2.F].
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic and activity, including lateral movement, on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host [CPG 3.A].
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.
  • Disable unused ports and protocols [CPG 2.V].
  • Consider adding an email banner to emails received from outside your organization [CPG 2.M].
  • Disable hyperlinks in received emails.
  • Ensure all backup data is encrypted, immutable (i.e., ensure backup data cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, the FBI, CISA, and MS-ISAC recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The FBI, CISA, and MS-ISAC recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Tables 4-16).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The FBI, CISA, and MS-ISAC recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

REFERENCES

[1] Privacy Affairs: “Moral” 8Base Ransomware Targets 2 New Victims
[2] VMware: 8base ransomware: A Heavy Hitting Player
[3] Infosecurity Magazine: Phobos Ransomware Family Expands With New FAUST Variant
[4] The Record: Hospitals offline across Romania following ransomware attack on IT platform
[5] Comparitech: What is Phobos Ransomware & How to Protect Against It?
[6] Cisco Talos: Understanding the Phobos affiliate structure and activity
[7] Cisco Talos: A deep dive into Phobos ransomware, recently deployed by 8Base group
[8] Malwarebytes Labs: A deep dive into Phobos ransomware
[9] Any Run: Smokeloader
[10] Malpedia: Smokeloader
[11] Truesec: A case of the FAUST Ransomware
[12] VirusTotal: Phobos Domain #1
[13] VirusTotal: Phobos executable: Ahpdate.exe
[14] VirusTotal: Phobos GUI extension: ELF File
[15] VirusTotal: Phobos IP address: 185.202.0[.]111
[16] VirusTotal: Phobos GUI extension: Binary File
[17] Cisco Talos GitHub: IOCs/2023/11/deep-dive-into-phobos-ransomware.txt at main

REPORTING

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom-note, communications with Phobos actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details requested include: a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host and network-based indicators.

The FBI and CISA do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to the FBI Internet Crime Complaint Center (IC3), a local FBI Field Office, or to CISA at report@cisa.gov or (888) 282-0870.

DISCLAIMER

The FBI does not conduct its investigative activities or base attribution solely on activities protected by the First Amendment. Your company has no obligation to respond or provide information back to the FBI in response to this engagement. If, after reviewing the information, your company decides to provide referral information to the FBI, it must do so in a manner consistent with federal law. The FBI does not request or expect your company to take any particular action regarding this information other than holding it in confidence due to its sensitive nature.

The information in this report is being provided “as is” for informational purposes only. The FBI and CISA not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise does not constitute or imply endorsement, recommendation, or favoring by CISA, the FBI, and the MS-ISAC.

ACKNOWLEDGEMENTS

The California Joint Regional Intelligence Center (JRIC, CA) and Israel National Cyber Directorate (INCD) contributed to this CSA.

VERSION HISTORY

February 29, 2024: Initial version.

Utilizing the VirusTotal API to Query Files Uploaded to DShield Honeypot [Guest Diary], (Sun, Feb 25th)

This post was originally published on this site

[This is a Guest Diary by Keegan Hamlin, an ISC intern as part of the SANS.edu BACS program]

Part of the SANS undergraduate program is a 20-week internship with the SANS Internet Storm Center. During that time, interns are tasked with setting up a DShield sensor to act as a honeypot, capturing data and generating logs for SSH/Telnet, Firewall activity, Web requests, and most interesting to me, file uploads. With those logs, we are expected to create attack observations, explaining what vulnerability is being exploited, what the attacker is attempting to accomplish, and how to defend against this attack. I wanted to give myself a project to help aid with creating these attack observations, and in my case, a way to quickly get information on the uploaded files. At the beginning of the internship, I had given myself a personal goal, which was to do something to build my Python skills. I thought this might be the opportunity to do that.

VirusTotal is a go-to source to upload or search for hashes of suspicious files and it is what I typically use when investigating files uploaded to the honeypot. They offer an API to automate this process, and it integrates well with Python.

Simple Command Line Query

I began by following the steps listed in the VirusTotal quick start page for their Python integration tool vt-py. [1]

You can install this package in several way, but I simply used pip:
$ pip install vt-py

After playing around with the tool in a Python interactive session, I wrote a simple script that takes a file hash as a command line argument:

import vt
import sys

try:
    file_hash = sys.argv[1]
except IndexError:
    print("ERROR: You must supply a file hash.")
    sys.exit(1)

# //// VIRUSTOTAL API KEY ////
API = # CHANGE THIS TO YOUR VIRUSTOTAL API KEY

client = vt.Client(API)

file = client.get_object(f"/files/{file_hash}")

analysis = file.last_analysis_stats

for x,y in analysis.items():
    print(x.title(),":",y)

client.close()

The output looks like this:

$ python vt_simple.py 57e9955208af9bc1035bd7cd2f7da1db19ea73857bea664375855f693a6280d8
Malicious : 37
Suspicious : 0
Undetected : 22
Harmless : 0
Timeout : 0
Confirmed-Timeout : 0
Failure : 1
Type-Unsupported : 15

This doesn’t give a whole lot of information, however while investigating an attack, it is a quick way to check to see if a file has been analyzed and is being tracked as malicious.

I wanted more though. I wanted a way to automate submissions of all the files within the Cowrie /downloads directory and output in a format that would make it easy to quickly scan to determine which files might need further analysis.

Full Scan of Cowrie Downloads Directory

There were a couple of things I needed to keep in mind before writing this script. For one, the VirusTotal API has limitations on the frequency and number of queries for a free-tier account. Those are 4 lookups/min, 500/day, 15.5 K/month. There is no way that I would hit the daily or monthly limits, but I had to make sure the script didn’t perform more than 4 queries a minute. Easy enough to manage by adding a pause between each lookup. However, depending on the number of files in the download’s directory, this does mean that the script will take some time to complete the first time it is run.

Another aspect that I wanted to keep in mind was that I did not want the script to query files that it had already retrieved data on. There might be some spaghetti coding going on here, but to prevent that from happening, I had the script make a separate file_hashes.txt file that holds all the hashes that have been used to query VirusTotal already.
In the Cowrie download directory, all the filenames should already be the SHA256 hash of the file. In my case, there were a few that were not. I had already added a try/except block in my function that queries VirusTotal so that if a query fails, it won’t send an error to the console and end the program. To cover my bases and ensure that an actual file hash gets submitted, I added an if/else block to check if the filename is equal to 64 characters. This might not be the best way, but it makes it so that the program isn’t needlessly hashing each file, especially considering most of them are already renamed to the appropriate file hash.

This led me down a path to figure out how to hash a file in Python. In the Linux terminal, it’s easy as running the sha256sum command and you get the hash. I already knew of the Python hashlib module but was unsure of how to implement it into hashing a file. After some Google searching, I came across a page that was exactly what I was looking for [2]. Here is the code:

# Python program to find SHA256 hash string of a file
import hashlib
 
filename = input("Enter the input file name: ")
sha256_hash = hashlib.sha256()
with open(filename,"rb") as f:
    # Read and update hash string value in blocks of 4K
    for byte_block in iter(lambda: f.read(4096),b""):
        sha256_hash.update(byte_block)
    print(sha256_hash.hexdigest())

Just for the sake of learning more, I asked ChatGPT how I would go about hashing a file in Python and it gave me an almost verbatim answer. I’m thinking either ChatGPT sourced its response from the page I found, or vice-versa. Either way, I got what I was looking for and learned a little bit about the process of hashing a file.

The output of this program is a simple database in the form of a CSV. Viewing it in the terminal is horrendous. Obviously transferring it out to a host machine is needed, either by scp or even nc, but I found it easy enough to copy/paste into a blank notepad, saving as a ‘.csv’ and opening in Excel (or CSV viewer of your choice). The results look like this:

For times that I would like to stay in the terminal and to take a quick glance at the database, I added a function in the program to output a second plain text document that formats it in a way that is legible. There’s no sorting capability, and it may not be the best looking, but it is nice to have a quick way to pull up and review while investigating attacks without having to leave the terminal. There were a couple of different ways to get a csv to pretty print in the terminal, like Pretty Tables, but I liked the way this looked. It isn’t my code, however. I found it in a Stack Overflow post [3]. It looks like this:

Both scripts can be found on my Github:
https://github.com/ham-sauce/vt_cowrie

By the time I implemented this script in my DShield sensor, it had already been running for several months, so I had quite a few files that needed processed, roughly 160. At 4 queries a minute, it took about 40 minutes for the initial run. Once the initial database is made, running the script again will not take nearly as long. The way I have been using it is to periodically run it every few days. If it takes longer than an instant to complete, then I know there is something new added to the downloads directory (there is also an alert printed to the console stating which hash is being queried). 

I really only scratched the surface of what can be done with the VirusTotal API. There is definitely room to refine this script, make it more robust and tweak it in a way to gather more data.

Next Steps: Simple Malware Analysis

Using the above output from the script, I want to try to find something interesting to investigate. I sort the list of files by ‘UNDETECTED’, as I feel that if a file is being reported as malicious, there are already plenty of analysis reports that I can look up.

In my case, many of these undetected files were not worth much more investigating, as many of them were simple ASCII text files containing one or two bash commands. But it’s a good starting point.

Static Analysis

I only do a couple of things in regard to static analysis, and I will accomplish this in the DShield terminal. 
First, I will run the file command on the file of interest, getting something like this:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, missing section headers

And then I will run the strings command. Which rarely gets back anything useful, but sometimes there will be a string or two worthwhile. Like the following:
$Info: This file is packed with the UPX executable packer http://upx.sf.net $

At this point, I will move the file to an analysis virtual machine, either FlareVM or REMNUX. To do this somewhat safely, I like to zip it and password protect it like so:
zip –password infected mal.zip </path/to/file>

And then scp it to my host of choice.

Dynamic/Behavioral Analysis

When I first started this post, I really wanted to get my hands on Mockingbird from Assured Information Security. [4] It is an automated malware analysis environment based off the Cuckoo Sandbox. I had used it at my previous job, and it is extremely easy to use. It comes pre-configured; all you must do is load it up in either ESXi or VMware Workstation. According to the data sheet, they have an evaluation copy available, but unfortunately the company never got back to me.

The official Cuckoo Sandbox is no longer supported. However, there are several forks available such as cuckoo3 [5] and CAPEv2 [6]. Setting either of those up is a bit of an undertaking, not for the faint of heart. I ran into issues that I couldn’t resolve in a timely manner, and it all seemed a bit out of scope for what I was trying to accomplish, so I abandoned this idea.

There are numerous web-based automated malware analyzers out there. Unfortunately, most of them only support Windows executable, at least in the free tier. And with the DShield honeypot being Linux based, pretty much any malware uploaded to it is going to be an ELF executable or bash script. Surprisingly, as I was writing this, ANY.RUN [7] released a Linux environment to analyze malware.

It is very simple to use. After creating an account and signing in, click the new task button:

Drag and drop your file into the window and select Ubuntu:

The app will then run the executable in an Ubuntu virtual environment and generate a report for review. There are numerous indicators that can be further investigated, such as process information which includes command line arguments, file activity, and network activity like connections made or DNS requests. At that point, you could correlate some of this data with other attacks made against the honeypot and possibly find even more rabbit holes to go down.

Final Thoughts

This is obviously not a full deep dive into malware analysis. My goal was to create a simple process for myself to assist with researching the events taking place on my DShield honeypot. There is plenty of room for this grow, and there is so much information out there on doing proper malware analysis.

[1] https://virustotal.github.io/vt-py/quickstart.html
[2] https://www.quickprogrammingtips.com/python/how-to-calculate-sha256-hash-of-a-file-in-python.html
[3] https://stackoverflow.com/questions/52520711/how-to-output-csv-data-to-terminal-with-python
[4] https://www.ainfosec.com/rd/mockingbird/
[5] https://github.com/cert-ee/cuckoo3
[6] https://github.com/kevoreilly/CAPEv2
[7] https://app.any.run/
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Update: MGLNDD_* Scans, (Sat, Feb 24th)

This post was originally published on this site

Almost 2 years ago, a reader asked us about TCP connections they observed. The data of these TCP connections starts with "MGLNDD_": "MGLNDD_* Scans".

Reader Michal Soltysik reached out to us with an answer: MGLN is Magellan, RIPE Atlas Tools. RIPE Atlas employs a global network of probes that measure Internet connectivity and reachability.

Thanks to Michal for explaining this in a video.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

SVR Cyber Actors Adapt Tactics for Initial Cloud Access

This post was originally published on this site

How SVR-Attributed Actors are Adapting to the Move of Government and Corporations to Cloud Infrastructure

OVERVIEW

This advisory details recent tactics, techniques, and procedures (TTPs) of the group commonly known as APT29, also known as Midnight Blizzard, the Dukes, or Cozy Bear.

The UK National Cyber Security Centre (NCSC) and international partners assess that APT29 is a cyber espionage group, almost certainly part of the SVR, an element of the Russian intelligence services. The US National Security Agency (NSA), the US Cybersecurity and Infrastructure Security Agency (CISA), the US Cyber National Mission Force (CNMF), the Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the Canadian Centre for Cyber Security (CCCS), and New Zealand Government Communications Security Bureau (GCSB) agree with this attribution and the details provided in this advisory.

This advisory provides an overview of TTPs deployed by the actor to gain initial access into the cloud environment and includes advice to detect and mitigate this activity.

To download the PDF version of this report, click here.

PREVIOUS ACTOR ACTIVITY

The NCSC has previously detailed how Russian Foreign Intelligence Service (SVR) cyber actors have targeted governmental, think tank, healthcare, and energy targets for intelligence gain. It has now observed SVR actors expanding their targeting to include aviation, education, law enforcement, local and state councils, government financial departments, and military organizations.

SVR actors are also known for:

EVOLVING TTPs

As organizations continue to modernize their systems and move to cloud-based infrastructure, the SVR has adapted to these changes in the operating environment.

They have to move beyond their traditional means of initial access, such as exploiting software vulnerabilities in an on-premises network, and instead target the cloud services themselves.

To access the majority of the victims’ cloud hosted network, actors must first successfully authenticate to the cloud provider. Denying initial access to the cloud environment can prohibit SVR from successfully compromising their target. In contrast, in an on-premises system, more of the network is typically exposed to threat actors.

Below describes in more detail how SVR actors are adapting to continue their cyber operations for intelligence gain. These TTPs have been observed in the last 12 months.

ACCESS VIA SERVICE AND DORMANT ACCOUNTS

Previous SVR campaigns reveal the actors have successfully used brute forcing [T1110] and password spraying to access service accounts. This type of account is typically used to run and manage applications and services. There is no human user behind them so they cannot be easily protected with multi-factor authentication (MFA), making these accounts more susceptible to a successful compromise. Service accounts are often also highly privileged depending on which applications and services they’re responsible for managing. Gaining access to these accounts provides threat actors with privileged initial access to a network, to launch further operations.

SVR campaigns have also targeted dormant accounts belonging to users who no longer work at a victim organization but whose accounts remain on the system [T1078.004].

Following an enforced password reset for all users during an incident, SVR actors have also been observed logging into inactive accounts and following instructions to reset the password. This has allowed the actor to regain access following incident response eviction activities.

CLOUD-BASED TOKEN AUTHENTICATION

Account access is typically authenticated by either username and password credentials or system-issued access tokens. The NCSC and partners have observed SVR actors using tokens to access their victims’ accounts, without needing a password [T1528].

The default validity time of system-issued tokens varies dependent on the system; however, cloud platforms should allow administrators to adjust the validity time as appropriate for their users. More information can be found on this in the mitigations section of this advisory.

ENROLLING NEW DEVICES TO THE CLOUD

On multiple occasions, the SVR have successfully bypassed password authentication on personal accounts using password spraying and credential reuse. SVR actors have also then bypassed MFA through a technique known as “MFA bombing” or “MFA fatigue,” in which the actors repeatedly push MFA requests to a victim’s device until the victim accepts the notification [T1621].

Once an actor has bypassed these systems to gain access to the cloud environment, SVR actors have been observed registering their own device as a new device on the cloud tenant [T1098.005]. If device validation rules are not set up, SVR actors can successfully register their own device and gain access to the network.

By configuring the network with device enrollment policies, there have been instances where these measures have defended against SVR actors and denied them access to the cloud tenant.

RESIDENTIAL PROXIES

As network-level defenses improve detection of suspicious activity, SVR actors have looked at other ways to stay covert on the internet. A TTP associated with this actor is the use of residential proxies [T1090.002]. Residential proxies typically make traffic appear to originate from IP addresses within internet service provider (ISP) ranges used for residential broadband customers and hide the true source. This can make it harder to distinguish malicious connections from typical users. This reduces the effectiveness of network defenses that use IP addresses as indicators of compromise, and so it is important to consider a variety of information sources such as application and host-based logging for detecting suspicious activity.

CONCLUSION

The SVR is a sophisticated actor capable of carrying out a global supply chain compromise such as the 2020 SolarWinds, however the guidance in this advisory shows that a strong baseline of cyber security fundamentals can help defend from such actors.

For organizations that have moved to cloud infrastructure, a first line of defense against an actor such as SVR should be to protect against SVR’s TTPs for initial access. By following the mitigations outlined in this advisory, organizations will be in a stronger position to defend against this threat.

Once the SVR gain initial access, the actor is capable of deploying highly sophisticated post compromise capabilities such as MagicWeb, as reported in 2022. Therefore, mitigating against the SVR’s initial access vectors is particularly important for network defenders.

CISA have also produced guidance through their Secure Cloud Business Applications (SCuBA) Project which is designed to protect assets stored in cloud environments.

Some of the TTPs listed in this report, such as residential proxies and exploitation of system accounts, are similar to those reported as recently as January 2024 by Microsoft.

MITRE ATT&CK®

This report has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

Tactic ID Technique Procedure

Credential Access

T1110

Brute Force

The SVR use password spraying and brute forcing as an initial infection vector.

Initial Access

T1078.004

Valid Accounts: Cloud Accounts

The SVR use compromised credentials to gain access to accounts for cloud services, including system and dormant accounts.

Credential Access

T1528

Steal Application Access Token

The SVR use stolen access tokens to login to accounts without the need for passwords.

Credential Access

T1621

Multi-Factor Authentication Request Generation

The SVR repeatedly push MFA requests to a victim’s device until the victim accepts the notification, providing SVR access to the account.

Command and Control

T1090.002

Proxy: External Proxy

The SVR use open proxies in residential IP ranges to blend in with expected IP address pools in access logs.

Persistence

T1098.005

Account Manipulation: Device Registration

The SVR attempt to register their own device on the cloud tenant after acquiring access to accounts.

MITIGATION AND DETECTION

A number of mitigations will be useful in defending against the activity described in this advisory: 

  • Use multi-factor authentication (/2-factor authentication/two-step verification) to reduce the impact of password compromises. See NCSC guidance: Multifactor Authentication for Online Services and Setting up 2-Step Verification (2SV).
  • Accounts that cannot use 2SV should have strong, unique passwords. User and system accounts should be disabled when no longer required with a “joiners, movers, and leavers” process in place and regular reviews to identify and disable inactive/dormant accounts. See NCSC guidance: 10 Steps to Cyber Security.
  • System and service accounts should implement the principle of least privilege, providing tightly scoped access to resources required for the service to function.
  • Canary service accounts should be created which appear to be valid service accounts but are never used by legitimate services. Monitoring and alerting on the use of these account provides a high confidence signal that they are being used illegitimately and should be investigated urgently.
  • Session lifetimes should be kept as short as practical to reduce the window of opportunity for an adversary to use stolen session tokens. This should be paired with a suitable authentication method that strikes a balance between regular user authentication and user experience.
  • Ensure device enrollment policies are configured to only permit authorized devices to enroll. Use zero-touch enrollment where possible, or if self-enrollment is required then use a strong form of 2SV that is resistant to phishing and prompt bombing. Old devices should be prevented from (re)enrolling when no longer required. See NCSC guidance: Device Security Guidance.
  • Consider a variety of information sources such as application events and host-based logs to help prevent, detect and investigate potential malicious behavior. Focus on the information sources and indicators of compromise that have a better rate of false positives. For example, looking for changes to user agent strings that could indicate session hijacking may be more effective than trying to identify connections from suspicious IP addresses. See NCSC guidance: Introduction to Logging for Security Purposes.

DISCLAIMER

This report draws on information derived from NCSC and industry sources. Any NCSC findings and recommendations made have not been provided with the intention of avoiding all risks and following the recommendations will not remove all such risk. Ownership of information risks remains with the relevant system owner at all times.

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation.

Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk.

All material is UK Crown Copyright.