Login
CrimsonEDR is an open-source project engineered to identify specific malware patterns, offering a tool for honing skills in circumventing Endpoint Detection and Response (EDR). By leveraging diverse detection methods, it empowers users to deepen their understanding of security evasion tactics.
| Detection | Description |
|---|---|
| Direct Syscall | Detects the usage of direct system calls, often employed by malware to bypass traditional API hooks. |
| NTDLL Unhooking | Identifies attempts to unhook functions within the NTDLL library, a common evasion technique. |
| AMSI Patch | Detects modifications to the Anti-Malware Scan Interface (AMSI) through byte-level analysis. |
| ETW Patch | Detects byte-level alterations to Event Tracing for Windows (ETW), commonly manipulated by malware to evade detection. |
| PE Stomping | Identifies instances of PE (Portable Executable) stomping. |
| Reflective PE Loading | Detects the reflective loading of PE files, a technique employed by malware to avoid static analysis. |
| Unbacked Thread Origin | Identifies threads originating from unbacked memory regions, often indicative of malicious activity. |
| Unbacked Thread Start Address | Detects threads with start addresses pointing to unbacked memory, a potential sign of code injection. |
| API hooking | Places a hook on the NtWriteVirtualMemory function to monitor memory modifications. |
| Custom Pattern Search | Allows users to search for specific patterns provided in a JSON file, facilitating the identification of known malware signatures. |
To get started with CrimsonEDR, follow these steps:
FreshRSS bash sudo apt-get install gcc-mingw-w64-x86-64
bash git clone https://github.com/Helixo32/CrimsonEDR
bash cd CrimsonEDR; chmod +x compile.sh; ./compile.sh
Windows Defender and other antivirus programs may flag the DLL as malicious due to its content containing bytes used to verify if the AMSI has been patched. Please ensure to whitelist the DLL or disable your antivirus temporarily when using CrimsonEDR to avoid any interruptions.
To use CrimsonEDR, follow these steps:
ioc.json file is placed in the current directory from which the executable being monitored is launched. For example, if you launch your executable to monitor from C:\Users\admin\, the DLL will look for ioc.json in C:\Users\admin\ioc.json. Currently, ioc.json contains patterns related to msfvenom. You can easily add your own in the following format:{
"IOC": [
["0x03", "0x4c", "0x24", "0x08", "0x45", "0x39", "0xd1", "0x75"],
["0xf1", "0x4c", "0x03", "0x4c", "0x24", "0x08", "0x45", "0x39"],
["0x58", "0x44", "0x8b", "0x40", "0x24", "0x49", "0x01", "0xd0"],
["0x66", "0x41", "0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40"],
["0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40", "0x1c", "0x49"],
["0x01", "0xc1", "0x38", "0xe0", "0x75", "0xf1", "0x4c", "0x03"],
["0x24", "0x49", "0x01", "0xd0", "0x66", "0x41", "0x8b", "0x0c"],
["0xe8", "0xcc", "0x00", "0x00", "0x00", "0x41", "0x51", "0x41"]
]
}
Execute CrimsonEDRPanel.exe with the following arguments:
-d <path_to_dll>: Specifies the path to the CrimsonEDR.dll file.
-p <process_id>: Specifies the Process ID (PID) of the target process where you want to inject the DLL.
For example:
.\CrimsonEDRPanel.exe -d C:\Temp\CrimsonEDR.dll -p 1234
Here are some useful resources that helped in the development of this project:
For questions, feedback, or support, please reach out to me via:
There are indications that U.S. healthcare giant Change Healthcare has made a $22 million extortion payment to the infamous BlackCat ransomware group (a.k.a. “ALPHV“) as the company struggles to bring services back online amid a cyberattack that has disrupted prescription drug services nationwide for weeks. However, the cybercriminal who claims to have given BlackCat access to Change’s network says the crime gang cheated them out of their share of the ransom, and that they still have the sensitive data Change reportedly paid the group to destroy. Meanwhile, the affiliate’s disclosure appears to have prompted BlackCat to cease operations entirely.
Image: Varonis.
In the third week of February, a cyber intrusion at Change Healthcare began shutting down important healthcare services as company systems were taken offline. It soon emerged that BlackCat was behind the attack, which has disrupted the delivery of prescription drugs for hospitals and pharmacies nationwide for nearly two weeks.
On March 1, a cryptocurrency address that security researchers had already mapped to BlackCat received a single transaction worth approximately $22 million. On March 3, a BlackCat affiliate posted a complaint to the exclusive Russian-language ransomware forum Ramp saying that Change Healthcare had paid a $22 million ransom for a decryption key, and to prevent four terabytes of stolen data from being published online.
The affiliate claimed BlackCat/ALPHV took the $22 million payment but never paid him his percentage of the ransom. BlackCat is known as a “ransomware-as-service” collective, meaning they rely on freelancers or affiliates to infect new networks with their ransomware. And those affiliates in turn earn commissions ranging from 60 to 90 percent of any ransom amount paid.
“But after receiving the payment ALPHV team decide to suspend our account and keep lying and delaying when we contacted ALPHV admin,” the affiliate “Notchy” wrote. “Sadly for Change Healthcare, their data [is] still with us.”
Change Healthcare has neither confirmed nor denied paying, and has responded to multiple media outlets with a similar non-denial statement — that the company is focused on its investigation and on restoring services.
Assuming Change Healthcare did pay to keep their data from being published, that strategy seems to have gone awry: Notchy said the list of affected Change Healthcare partners they’d stolen sensitive data from included Medicare and a host of other major insurance and pharmacy networks.
On the bright side, Notchy’s complaint seems to have been the final nail in the coffin for the BlackCat ransomware group, which was infiltrated by the FBI and foreign law enforcement partners in late December 2023. As part of that action, the government seized the BlackCat website and released a decryption tool to help victims recover their systems.
BlackCat responded by re-forming, and increasing affiliate commissions to as much as 90 percent. The ransomware group also declared it was formally removing any restrictions or discouragement against targeting hospitals and healthcare providers.
However, instead of responding that they would compensate and placate Notchy, a representative for BlackCat said today the group was shutting down and that it had already found a buyer for its ransomware source code.
The seizure notice now displayed on the BlackCat darknet website.
“There’s no sense in making excuses,” wrote the RAMP member “Ransom.” “Yes, we knew about the problem, and we were trying to solve it. We told the affiliate to wait. We could send you our private chat logs where we are shocked by everything that’s happening and are trying to solve the issue with the transactions by using a higher fee, but there’s no sense in doing that because we decided to fully close the project. We can officially state that we got screwed by the feds.”
BlackCat’s website now features a seizure notice from the FBI, but several researchers noted that this image seems to have been merely cut and pasted from the notice the FBI left in its December raid of BlackCat’s network. The FBI has not responded to requests for comment.
Fabian Wosar, head of ransomware research at the security firm Emsisoft, said it appears BlackCat leaders are trying to pull an “exit scam” on affiliates by withholding many ransomware payment commissions at once and shutting down the service.
“ALPHV/BlackCat did not get seized,” Wosar wrote on Twitter/X today. “They are exit scamming their affiliates. It is blatantly obvious when you check the source code of their new takedown notice.”
Dmitry Smilyanets, a researcher for the security firm Recorded Future, said BlackCat’s exit scam was especially dangerous because the affiliate still has all the stolen data, and could still demand additional payment or leak the information on his own.
“The affiliates still have this data, and they’re mad they didn’t receive this money, Smilyanets told Wired.com. “It’s a good lesson for everyone. You cannot trust criminals; their word is worth nothing.”
BlackCat’s apparent demise comes closely on the heels of the implosion of another major ransomware group — LockBit, a ransomware gang estimated to have extorted over $120 million in payments from more than 2,000 victims worldwide. On Feb. 20, LockBit’s website was seized by the FBI and the U.K.’s National Crime Agency (NCA) following a months-long infiltration of the group.
LockBit also tried to restore its reputation on the cybercrime forums by resurrecting itself at a new darknet website, and by threatening to release data from a number of major companies that were hacked by the group in the weeks and days prior to the FBI takedown.
But LockBit appears to have since lost any credibility the group may have once had. After a much-promoted attack on the government of Fulton County, Ga., for example, LockBit threatened to release Fulton County’s data unless paid a ransom by Feb. 29. But when Feb. 29 rolled around, LockBit simply deleted the entry for Fulton County from its site, along with those of several financial organizations that had previously been extorted by the group.
Fulton County held a press conference to say that it had not paid a ransom to LockBit, nor had anyone done so on their behalf, and that they were just as mystified as everyone else as to why LockBit never followed through on its threat to publish the county’s data. Experts told KrebsOnSecurity LockBit likely balked because it was bluffing, and that the FBI likely relieved them of that data in their raid.
Smilyanets’ comments are driven home in revelations first published last month by Recorded Future, which quoted an NCA official as saying LockBit never deleted the data after being paid a ransom, even though that is the only reason many of its victims paid.
“If we do not give you decrypters, or we do not delete your data after payment, then nobody will pay us in the future,” LockBit’s extortion notes typically read.
Hopefully, more companies are starting to get the memo that paying cybercrooks to delete stolen data is a losing proposition all around.
The ransomware group LockBit told officials with Fulton County, Ga. they could expect to see their internal documents published online this morning unless the county paid a ransom demand. LockBit removed Fulton County’s listing from its victim shaming website this morning, claiming the county had paid. But county officials said they did not pay, nor did anyone make payment on their behalf. Security experts say LockBit was likely bluffing and probably lost most of the data when the gang’s servers were seized this month by U.S. and U.K. law enforcement.
The LockBit website included a countdown timer until the promised release of data stolen from Fulton County, Ga. LockBit would later move this deadline up to Feb. 29, 2024.
LockBit listed Fulton County as a victim on Feb. 13, saying that unless it was paid a ransom the group would publish files stolen in a breach at the county last month. That attack disrupted county phones, Internet access and even their court system. LockBit leaked a small number of the county’s files as a teaser, which appeared to include sensitive and sealed court records in current and past criminal trials.
On Feb. 16, Fulton County’s entry — along with a countdown timer until the data would be published — was removed from the LockBit website without explanation. The leader of LockBit told KrebsOnSecurity this was because Fulton County officials had engaged in last-minute negotiations with the group.
But on Feb. 19, investigators with the FBI and the U.K.’s National Crime Agency (NCA) took over LockBit’s online infrastructure, replacing the group’s homepage with a seizure notice and links to LockBit ransomware decryption tools.
In a press briefing on Feb. 20, Fulton County Commission Chairman Robb Pitts told reporters the county did not pay a ransom demand, noting that the board “could not in good conscience use Fulton County taxpayer funds to make a payment.”
Three days later, LockBit reemerged with new domains on the dark web, and with Fulton County listed among a half-dozen other victims whose data was about to be leaked if they refused to pay. As it does with all victims, LockBit assigned Fulton County a countdown timer, saying officials had until late in the evening on March 1 until their data was published.
LockBit revised its deadline for Fulton County to Feb. 29.
LockBit soon moved up the deadline to the morning of Feb. 29. As Fulton County’s LockBit timer was counting down to zero this morning, its listing disappeared from LockBit’s site. LockBit’s leader and spokesperson, who goes by the handle “LockBitSupp,” told KrebsOnSecurity today that Fulton County’s data disappeared from their site because county officials paid a ransom.
“Fulton paid,” LockBitSupp said. When asked for evidence of payment, LockBitSupp claimed. “The proof is that we deleted their data and did not publish it.”
But at a press conference today, Fulton County Chairman Robb Pitts said the county does not know why its data was removed from LockBit’s site.
“As I stand here at 4:08 p.m., we are not aware of any data being released today so far,” Pitts said. “That does not mean the threat is over. They could release whatever data they have at any time. We have no control over that. We have not paid any ransom. Nor has any ransom been paid on our behalf.”
Brett Callow, a threat analyst with the security firm Emsisoft, said LockBit likely lost all of the victim data it stole before the FBI/NCA seizure, and that it has been trying madly since then to save face within the cybercrime community.
“I think it was a case of them trying to convince their affiliates that they were still in good shape,” Callow said of LockBit’s recent activities. “I strongly suspect this will be the end of the LockBit brand.”
Others have come to a similar conclusion. The security firm RedSense posted an analysis to Twitter/X that after the takedown, LockBit published several “new” victim profiles for companies that it had listed weeks earlier on its victim shaming site. Those victim firms — a healthcare provider and major securities lending platform — also were unceremoniously removed from LockBit’s new shaming website, despite LockBit claiming their data would be leaked.
“We are 99% sure the rest of their ‘new victims’ are also fake claims (old data for new breaches),” RedSense posted. “So the best thing for them to do would be to delete all other entries from their blog and stop defrauding honest people.”
Callow said there certainly have been plenty of cases in the past where ransomware gangs exaggerated their plunder from a victim organization. But this time feels different, he said.
“It is a bit unusual,” Callow said. “This is about trying to still affiliates’ nerves, and saying, ‘All is well, we weren’t as badly compromised as law enforcement suggested.’ But I think you’d have to be a fool to work with an organization that has been so thoroughly hacked as LockBit has.”
py-amsi is a library that scans strings or files for malware using the Windows Antimalware Scan Interface (AMSI) API. AMSI is an interface native to Windows that allows applications to ask the antivirus installed on the system to analyse a file/string. AMSI is not tied to Windows Defender. Antivirus providers implement the AMSI interface to receive calls from applications. This library takes advantage of the API to make antivirus scans in python. Read more about the Windows AMSI API here.
Via pip
pip install pyamsi
Clone repository
git clone https://github.com/Tomiwa-Ot/py-amsi.git
cd py-amsi/
python setup.py installfrom pyamsi import Amsi
# Scan a file
Amsi.scan_file(file_path, debug=True) # debug is optional and False by default
# Scan string
Amsi.scan_string(string, string_name, debug=False) # debug is optional and False by default
# Both functions return a dictionary of the format
# {
# 'Sample Size' : 68, // The string/file size in bytes
# 'Risk Level' : 0, // The risk level as suggested by the antivirus
# 'Message' : 'File is clean' // Response message
# }| Risk Level | Meaning |
|---|---|
| 0 | AMSI_RESULT_CLEAN (File is clean) |
| 1 | AMSI_RESULT_NOT_DETECTED (No threat detected) |
| 16384 | AMSI_RESULT_BLOCKED_BY_ADMIN_START (Threat is blocked by the administrator) |
| 20479 | AMSI_RESULT_BLOCKED_BY_ADMIN_END (Threat is blocked by the administrator) |
| 32768 | AMSI_RESULT_DETECTED (File is considered malware) |
https://tomiwa-ot.github.io/py-amsi/index.html
MSI Dump - a tool that analyzes malicious MSI installation packages, extracts files, streams, binary data and incorporates YARA scanner.
On Macro-enabled Office documents we can quickly use oletools mraptor to determine whether document is malicious. If we want to dissect it further, we could bring in oletools olevba or oledump.
To dissect malicious MSI files, so far we had only one, but reliable and trustworthy lessmsi. However, lessmsi doesn't implement features I was looking for:
Hence this is where msidump comes into play.
This tool helps in quick triages as well as detailed examinations of malicious MSIs corpora. It lets us:
file/MIME type deduction to determine inner data typeIt was created as a companion tool to the blog post I released here:
WindowsInstaller.Installer interfaces, currently it is not possible to support native Linux platforms. Maybe wine python msidump.py could help, but haven't tried that yet.cmd> python msidump.py evil.msi -y rules.yara
Here we can see that input MSI is injected with suspicious VBScript and contains numerous executables in it.
We see from the triage table that it was present in Binary table. Lets get him:
python msidump.py putty-backdoored.msi -l binary -i UBXtHArj
We can specify which to record dump either by its name/ID or its index number (here that would be 7).
Lets have a look at another example. This time there is executable stored in Binary table that will be executed during installation:
To extract that file we're gonna go with
python msidump.py evil2.msi -x binary -i lmskBju -O extracted
Where
-x binary tells to extract contents of Binary table-i lmskBju specifies which record exactly to extract-O extracted sets output directoryFor the best output experience, run the tool on a maximized console window or redirect output to file:
python msidump.py [...] -o analysis.log
PS D:\> python .\msidump.py --help
options:
-h, --help show this help message and exit
Required arguments:
infile Input MSI file (or directory) for analysis.
Options:
-q, --quiet Surpress banner and unnecessary information. In triage mode, will display only verdict.
-v, --verbose Verbose mode.
-d, --debug Debug mode.
-N, --nocolor Dont use colors in text output.
-n PRINT_LEN, --print-len PRINT_LEN
When previewing data - how many bytes to include in preview/hexdump. Default: 128
-f {text,json,csv}, --format {text,json,csv}
Output format: text, json, csv. Default: text
-o path, --outfile path
Redirect program output to this file.
-m, --mime When sniffing inner data type, report MIME types
Analysis Modes:
-l what, --list what List specific table contents. See help message to learn what can be listed.
-x what, --extract what
Extract data from MSI. For what can be extracted, refer to help message.
Analysis Specific options:
-i number|name, --record number|name
Can be a number or name. In --list mode, specifies which record to dump/display entirely. In --extract mode dumps only this particular record to --outdir
-O path, --outdir path
When --extract mode is used, specifies output location where to extract data.
-y path, --yara path Path to YARA rule/directory with rules. YARA will be matched against Binary data, streams and inner files
------------------------------------------------------
- What can be listed:
--list CustomAction - Specific table
--lis t Registry,File - List multiple tables
--list stats - Print MSI database statistics
--list all - All tables and their contents
--list olestream - Prints all OLE streams & storages.
To display CABs embedded in MSI try: --list _Streams
--list cabs - Lists embedded CAB files
--list binary - Lists binary data embedded in MSI for its own purposes.
That typically includes EXEs, DLLs, VBS/JS scripts, etc
- What can be extracted:
--extract all - Extracts Binary data, all files from CABs, scripts from CustomActions
--extract binary - Extracts Binary data
--extract files - Extracts files
--extract cabs - Extracts cabinets
--extract scripts - Extrac ts scripts
------------------------------------------------------
CustomAction Types based on assessing their numbers, which is prone to being evaded. Apparently when naming my tool, I didn't think on checking whether it was already taken. There is another tool named msidump being part of msitools GNU package:
This and other projects are outcome of sleepless nights and plenty of hard work. If you like what I do and appreciate that I always give back to the community, Consider buying me a coffee (or better a beer) just to say thank you!
Mariusz Banach / mgeeky, (@mariuszbit)
<mb [at] binary-offensive.com>
