Networkforensic
Threat hunting
Astaroth/Guildma Banking Trojan
30 December 2021 - Blog Post # 809
Astaroth/Guildma Trojan
Astaroth/Guildma banking Trojan er i starten primært set
målrettet imod Brasilianske brugerer, men nu også i Europa. Først
set i 2017.
Meget støjende malware
Jeg må sige at det her malware støjer meget. Den forsøger simpelthen
for mange teknikker for at undgå at blive opdaget, men der findes
simpelthen for mange generiske signaturer til det her ikke bliver
opdaget ret hurtigt.
Alene i netværkstrafikken bimler og ringer det hele. Men der findes
dog ikke en egenteligt IDS signatur der peger og siger det er
Astaroth/Guildma
IDS rule frigivet
Ret præcise IDS rules, der kan spotte alle kampanger fra nu og
tilbage i tiden.
Log4j - SNORT IDS detection update
27 December 2021 - Blog Post # 808
Obfuscation
Log4J CVE-2021-44228 er virkelig noget der går lidt hurtigt i
udformninger af attacks. Mange IDS rules kan kun se når der er tale
om klar tekst protokoller i selve angrebet. Her trigger de færreste
IDS rules når det sker over https. Dog er det noget andet når der er
tale om backconnect. Her kan man finde mange ting man kan trigger
på.
NCCGroup
De har
frigivet en del pcaps med rigtig mange typer attacks. Det har
bevirket at jeg har lavet et samlet opdatering af alle de IDS rules
jeg selv lavede i starten, da Log4J først blev kendt. Jeg har
tilføjet en par stykker og fjernet en del af de gamle, så nu er der
11 IDS rules der dækker hvad der er set derude indtil nu.
IDS Rule frigivet
Log4J - 11 IDS rules. Der kan muligvis være falske positiver, men er
ikke pt stødt på nogen. I så flad vil jeg meget gerne høre om det,
såfremt det skulle være tilfældet.
Happy hunting og godt nytår.
Log4j - SMTP port
20 December 2021 - Blog Post # 807
Obfuscation
Log4J CVE-2021-44228 tager hurtigt mange former. Det
seneste jeg har set er brugen af obfuscation. Yderligerer ser jeg
det nu også benyttet imod SMTP port 25.
Wireshark filter
tcp contains 24:7b:24:7b:3a:3a:2d:6a:7d:6e:64:69:3a
IDS Rule frigivet
Kigger efter den obfuscation der er benyttet.
Angreb fra et IOT BotNet
16 December 2021 - Blog Post # 806
BotNet
Lidt skift af taktik. Det er lidt sjovt at se hvordan de
prøver at ændre taktik. Meget forsigtigt med et enkelt angreb
igennem Iraq. De udvikler med det
her eller det bruges af ham der laver botnettet. Et windows tool
til brug for wine.
IDS rule opdateret, samt en ny JA3.
Toolet lækker oplysninger ho ho
ho.......
JA3 Hash:
455bd65d382d4741f0e48654f27cbe80
Angreb fra et IOT BotNet
10 December 2021 - Blog Post # 805
BotNet angriber
Faldt over en række logs der viser forskellige typer
angreb. Password attacks, API jason token attacks og almindelige
port scanninger mm.
Angreb
Angreb sker typisk hen imod bl.a. krypteret mailport TCP 465. Typisk
ser man kun 1 login forsøg men typisk 3-5 IP adresser der angriber
inden for 1-2 minutter efter hianden. Så det er meget "Low and slow"
attacks jeg ser, men konstante.
Valideringer
Jeg startede med at opsamle godt 800+ IP'er der ifølge loggen
angriber netop mail-test.dk domænet, men på en helt forkert server i
virkeligheden.
Alle IP'er der har deltaget i angreb, har jeg nmap scannet på en kort række porte. Alle IP
adresse har typisk porte 22 SSH åben som er den største synder. Her
skal man lige være vågen overfor at jeg "kun" har fundet 800+ IP
adresser. Det skyldes at jeg benytter en stor række at GEO
blokerings filters, så der er rigtige mange lande, der slet ikke
kommer ind i loggen. Så tallet kan i virkeligheden være meget højere.
Systemer er et meget bredt spektrum af IOT udstyr. Som eks
herunder (Der findes meget mere)
| HUAWEI Router | PRROCEND LTE ISP |
| EdgeRouter | Jenkins server |
| GPON Home Gateway | QNAP NAS Server |
| Ubiquiti NanoStation 5AC | RUCKUS Wireless ZoneDirector |
| BobCat Miner | 2008 small business Server |
| VeEX UX400PLUS | PakedgeWR-1 Router |
| HIKVision | SonicWALL firewall |
| cnPilot E400 | Microsoft Exchange SMTP |
| Zyxel USG60 | DIGI WR11 |
| Dahua webcam |
På rigtig mange af disse der især Dropbear-Ssh i sårbare
versioner. Dropbear-Ssh er bla også kendt for i en omskrevet version
at målrette energi
sektoren, hvor det er
BlackEnergy APT gruppen der står bag. Yderligere er
CryptoSink malwaren også kendt for at misbruge Dropbear-Ssh. Der
findes sikkert flere i rækken. Dropbear-Ssh er dog værd at nævne,
fordi det findes i så mange sårbare versioner derude, at det er
meget skræmmende. Kan godt forstå at APT/ Crime grupper hopper på dem, når de er
lige til at vade ind i.
Et billede af en IOT type af device der deltager i attacks. Denne
type billeder har jeg mange af.
Næsten alt dette udstyr har kritiske sårbarheder, default bruger
information opsat, der aldrig er skiftet. gamle firmware versioner.
Faktisk alt det som rigtig mange IT-Sikkerheds folk advare imod at
man gør.
Fælles for dem alle at de indgår i det samme IOT BotNet, da
de alle sammen udører det samme angreb imod samme mål. Herunder ses
en lille eksempel på et attacks, det kunne også være direkte imod
andre brugere, hvor der så ville stå noget med "wrong password"
Eksempel på et attack.
Det ukendte
Jeg er ret overbevist om det er relateret til
FritzFrog IOT Botnettet og kan også have relationer til
BotenaGo
Det er fordi jeg har set beskrivelser fra begge BotNET med de IOC'er
omkring åbne porte, være en del af den valideret IP'liste som jeg
har set angribe. JA3 hash passer så på begge BotNET. Men i bund og
grund tror jeg det er det samme. Dog anbefaler jeg man kigger på
FritzFrog, da det matcher bedst.
Identificering
JA3 Hash der er 100% unik. Det er ikke noget der er set tidligere.
JA3 er heller ikke publiceret nogen steder på Internettet som
værende noget kendt.
JA3 er klart at gå efter da den både kan finde inficeret udstyr samt
IP adresser der angriber.
JA3 løsninger anbefalet.
Har man ikke netværks løsninger idag implementeret i sin
infrastruktur der kan identificere angreb via JA3 hashing, så har
man i mine øjne et gabende hul i sin overvågning. Så den mulighed er
klart noget jeg anbefaler man har.
Anbefaling.
Man skal ikke etferlade SSH åben til hele internettet. Slå det fra
hvis det ikke bruges. Rigtig meget af det udstyr jeg har set som for
det meste er IOT udstyr har default SSH stående åben. Meget SSH køre
med gamle versioner helt tilbage fra 2013.
Udfordringen
Det er lagt fra det hele er småt IOT udstyr. Der er også store firewalls blandt
fra især en kendt producent. Disse er især kritiske da de i
princippet kan give FULD adgang til en hel virksomhed. Den store
udfordring med meget af det her udstyr, er at meget af det jo står i private hjem, hvor der ikke er nogen med de rette
kompetancer til at få det sat rigtigt op og firmware opdateret. Det
bliver også svært for noget rent faktisk at opdage at udstyret er
kompromitteret. Det er svært at stoppe et BotNet som dette, uden man
totalt overtager hele BotNettet og slår det ned.
Det ville også være fint såfremt IOT udstyr ikke bliver slogt med
porte åbne fra WAN siden. Det er så dårlig praksis, og producenter
der gør det, burde man måske overveje, om de overhovet har de rigtige
kompetancer til at tænke sikkerhed fra starten af.
JA3 Hash
JA3: f17ca639ecdcaa65b4521c49e3515ef9
IP liste med valideret attackers. -
(List updated 20-12-2021 - 1840 IP's of
IOT attacking bots)
Alle ip adresser i denne liste er valideret som være attackers. Det
er typisk IOT udstyr af mange forskellige slags.
Filnavn: RAW-IP-LIST-IOT-BOTNET.zip
SHA1: 95325e453bf44d15e97523b7f749a66ec608e185
PCAP file with an attack
Filnavn: IOT-Attack.zip
SHA1: 0c8b31996bba6c5668292ad111fbedf55199040f
IDS rule frigivet
Denne IDS rule kigger kun på angreb via PORT 465 imod ens
netværk. Typisk vil det også kræve at der står et mail-system og
modtager disse. Denne vil IKKE fange noget såfremt man selv har
inficeret udstyr. Her vil det kræve JA3 HASH. Eller man kan optage
noget trafik fra en inficeret hos der deltager i angrebet og sende
denne til mig. Så vil jeg med glæde lave en IDS rule der finder
inficeret udstyr.
HPE Integrated Lights-Out 4 (iLO 4)
21 Oktober 2021 - Blog Post # 804
iLO
iLO er velkendt. Det er bygget til remote management i server
systemer fra HP. Så man kan eks starte en sever der er slukket. Det
er basalt set en ekstra server i serveren, der er forbundet via
netværk. Det giver mange muligheder i sig selv. Eks en remote shell
direkte til hardwaren på serveren, eller muligheder for at mounte
forskellige medietyper som ISO filer, DVD drev, loade forskellige
image typer osv. Alt i alt et MEGET kraftfuldt værktøj.
Forskellige producenter af hardware har typisk deres egen løsninger
og der er mange forskellige af dem. Jeg har selv her tidligere
omtalt eks vPRO. Det er meget brugbare tools, såfremt man håndtere
dem rigtigt.
Management netværk
Det er ikke uden grund at producenterne typisk
anbefaler at remote management af hardware typisk kun er
anbefalet fra et oprettet netværk UDEN internet forbindelser. Man
skal derfor ikke forbinde sit remote management netværk med resten
af virksomheden heller ikke til jumphosts. Det vil typipsk kræve at
man har en fysisk klient der er placeret et sted i virksomheden og
fra denne kan man tilgå netværket der giver adgang til al hardwaren.
(Ikke noget remote hen til management klienten. Ja det betyder man
skal være fysisk tilstede for at foretage management af hardware i
eks et serverrum.
Jeg har hørt mange undskyldinger for at man gerne vil kunne tilgå
det fra internettet via jumphost. Men den går ikke... det skal være
et lukket netværk der er sepperat oprettet med egne switches osv.
Det er ikke nok med VLAN's på samme netværk der benytter samme
switches som alt muligt andet. Det er NO GO. Gør man det
alligevel skal man nok overveje hvilken jobtitle man har, for der
bør ikke stå noget med IT-Sikkerhed i den.
Scanning efter iLO
Man kan foretage scanninger efter iLO i sit eget netværk for at
identificere ubeskyttet iLO adgange med eks nmap
Patchninger og sårbarheds scanninger
iLO skal scannes og patches ligesom alt andet udstyr. Men jeg ser
desværre typisk at mange helt overset denne type adgange i deres
egne netværk. Der findes typisk slet ikke nogen processer for
håndteringer af disse eller noget ansvar der er tildelt. Det kører i
mange tilfælde i sin helt egen uovervåget verden. Man skal heller
ikke tror at at bare fordi man benytte forskellige cloud servises så
er man beskyttet. Jeg har også set cloud producenter der kommer til
at forbinde til forkerte netværk når patch kablerne sættes i
switches.
Ransomware og iLO
Det er bestemt
ikke noget nyt med ransomware og krypteret diske på hele
hardware systemer. Derfor bør nok være endnu mere efter det.
"Indicators"
Jeg har her frigivet lidt Indicators på at identificere iLO der kan
være ubeskytte eller placeret forkert. De er lavet på en default
opsat iLO 4. Jeg vil tro de også passer på andre versioner. (Siger
samtidigt tak for lån af hardware jeg fik lov til at teste på)
DHCP server logs
ILOCZ1723015T\x00 - Søg efter hvor ILO
indgår i hostnavnet. Typisk default navne for ILO.
Kibana
certificate_common_name: ILO*
uri.keyword:"/html/IRC.exe.manifest"
Agent Server respons: 303 See Other
Server: HPE-iLO-Server/
JA3S - Security Onion
HPE-iLO-Server/1.30 (Server) HTTPS
JA3S: 8863a99fb3623e273eec49e5e7037422
HASSH - Security Onion
SSH-2.0-mpSSH_0.2.1 (server)
HASSH:0df9d9433854fd68eb358a41df3335ae
Port scanninger (namp)
namp -p 22,80,443,17988,17990 -T4 -A -v <ip range>
Syslog Messages (Tilføjet: 27-10-2021)
Made for iLO 4 -
Firmware Version 2.78
Syslog.txt
IDS rules frigivet
De trigger uden falkse positiver. Dog har jeg ikke fremstillet noget
til Virtual Media porten. Den lånte hardware var desværre uden
licens. Det er krævet for at kunne benytte denne funktion. Dog
afventer jeg en system med iLO 5 og hvor licenser er i orden. Mere
herom til den tid.
Vær opmærksom at porte skal være sat rigtigt i forhold hvor du gerne
vil identificere iLO. I IDS reglen. NF - HPE-iLO - Remote
Console activated - sid:5027803; er det især vigtigt. Her skal man
benytte port nummeret som en del af IDS reglen. Ellers vi den
sikkert sprøjte mange falske positiver ud. Her skal man bare
omplacere porten i IDS reglen.
QUIC - Follow-up
17 Oktober 2021 - Blog Post # 803
QUIC - Malware
relationer.
Efter at have overvåget og kigget trafik igennem der
benytter QUIC og kigget på mange af de domæner og IP-adresser samt
lande de er relateret til. Så er der her en jeg lige vil gøre lidt
opmærksom på, som kaster rigtig meget røg af sig. Men folk jo selv dømme
hvordan det kan hænge sammen, for i virkeligheden er det lidt uvist
hvordan det hele hænger sammen endnu.
Russiske domæner
Ved at kigge på vk[.]com og vk[.]me som er relateret til Russiske IP
adresser, dukker der mange relationer op til malware der er målrettet
Android og Windows. Det er taget ud fra ren QUIC trafik. De nævente
domæner har endnu flere domæner der er relateret til en række
subdomæner som eksemplet herunder.
Via alm HTTPS Eller ?
Der ser på overfladen ud til at alle relationer
er relateret til HTTPS forbindelser. Men her skal man nok ikke lade
sig snyde. For INGEN ved reaelt hvad vi ikke kan se, som køre over
QUIC forbindelserne. Mange forbindelser jeg har set til disse
subdomæner er ren QUIC, men krypteret så der ikke er nogen mulighed
for at se hvad de reaelt gemmer disse. De tools som er her
VirusTotal kender ikke til QUIC protokollen. Så det er ikke
bedre end det er. Men der er plads til lidt mere malware og trafik
analyse. Måske der dukker et billede op på et tidspunkt. MEN indtil
da ville jeg nok være lidt forsigtig ved at tillade de omtalte
domæner. Det skal også siges at vejen frem er malware analyser af de
samples der er relateret til hvad vi ved kan stamme fra QUIC trafik.
Blokeringer af domæner
Jaaaa...igen skal man ikke lade sig snyde. For
husk på at en QUIC forbindelser ikke behøver at starte forfra med
DNS opslag osv. Den kan sagtens køre fint viderer, når den kommer
ind på en nyt netværk med chashed informationer som unikke
Connections ID's. Så vil der ikke komme nye DNS opsalg, hvor man
derved kan breake en forbindelse og det gør at et DNS filter
kan vise sig at være et meget svagt forsvar.
QUIC - Quick UDP Internet Connection
1 Oktober 2021 - Blog Post # 802
QUIC
Rigtig mange ved ikke hvad QUIC er i det daglig brug, men
de fleste bruger det hver dag. I
2018 belyste jeg
QUIC
en smule. QUIC er en opfundet ny protokol (fra 2012) og endeligt frigivet her i
2021 i version 1 udviklet af Google. Man vil også opdage at en udokumenteret version 1.1
allerede kan spottest i netværks trafik.
Det slår sig lidt op på at være en meget optimeret måde
hvorpå der kan oprettet internet forbindelser. Det er den bestemt
også må man sige og er egenteligt smukt arbejde der løser en del
udfordringer.
En forsigtigt estimat er at alle virksomheder i dag, ligger
på en forbrug hvor 20-30% af deres internet trafik er QUIC. Mange
ved det dog ikke, fordi de udstyr de har stående og som bla skal
håndtere deres sikkerhed slet ikke kan fortolke QUIC og derved
forstå hvad der sker i denne trafik. Den skaber flere
sikkerhedsmæssige bekymringer end den lige nu løser. Men set som en
alm forbruger en god sikkerhed (såfremt trafikken ikke er ondsindet
i sig selv)
Marketing
Som jeg ser QUIC, er det yderst flot design. Men min bekymring
omkring at, det vil kunne få hvad mange
kender som "super
cookies" til totalt at blegne.
Godt nok kan mange li Google og de ting de laver, men man skal huske
på hvordan Google tjener de fleste penge, som er på at tracke
brugerne. Det må man sige at QUIC bestemt også er meget egnet til,
da der ligger unikke Connections ID's i pakkerne. Det kan desuden
ske hen over flere forskellige netværk, hvor forbindelsen i
virkeligheden bare kan fortsættet uden den behøver at starte forfra,
som man kender det i dag med alm TCP handshakes osv. Kigger man også
på den på denne måde, er det en fantastisk protokol til at målrette
annoncer med, da man hele tiden ved hvem brugeren er uanset hvordan
de bevæger sig rundt.
Det betyder at er en forbindelse oprettet til eks youtube eller
ond-domæne, så behøver man ikke at se hele oprettelsen igen der
ligger forud, for at QUIC går i gang på det nye netværk. Så er det
bare QUIC der fortsætter på chashed information. Det betyder at eks
en inficeret maskine, der er inficeret uden for det "sikre net",
realt bare kan fortsætte sin krypteret trafik, som en blind
medløber i trafik strømmen uden dem der sidder på netværket kan se
hvad der sker andet en en forbindelse imellem 2 IP adresser.
Inspection
Foretager man det som mange kender som HTTPS scanning eller
TLS-Offload med forskellige typer middelboxes, hvor man i dag fifler
med med public certifikatet og installerede proxy certifikater på
klienter, så bemærk lige noget endnu mere vigtigt her, at
certifikater ser man ikke mere, da de kun udveksles fuldt krypteret.
Så i princippet er alle de løsninger af middelboxes som en del
virksomheder allerede har 100% virkningsløse imod QUIC.
Billede viser min Wireshark profil igang med QUIC
Merlin C2 Framework
I forbindelse med QUIC og udnyttelse af denne protokol, er der lavet
et C2 Framework "Merlin"
hvor Command And Control kan bygge på QUIC. Derved vil ting som x-fil
af stjålet date kunne gå fuldstændig under radar på stort set
samtlige netværks overvågnings enheder, unden en eneste mulighed for
at opdage at dette sker. Dette framework virker allerede i
Kali. Bestemt
værd at kigge på såfremt man er pen-tester.
Hvordan kan man finde QUIC
For at finde QUIC i en netværk hvor udstyr slet ikke forstår QUIC,
kan man faktisk kun kigge efter pakker der bliver sendt på UDP dst port 443. Jeg testede på en ældre version af Security Onion. Eneste
mulighed var at kigge efter de beskrevet pakker på UDP. Kan
derfor godt anbefale at benytte den nyeste version 2.x af Security
Onion og få installeret de nødvendige QUIC scripts.
Browsers og test af understøttelse
De fleste browseres i dag kan forstå QUIC og er enabled som
standard. Man skal typisk ændre default setting for at disable QUIC.
Især Chrome og Firefox har default fuld understøttelse.
Man kan desuden teste web-sites (web-servers) for understøttelse at de forskellige
versioner der har været fra første test versioner frem til i dag, via
dette test site.
https://http3check.net - Lidt overrasket blev jeg da selv da jeg
opdagede min egen web-udbyder rent faktisk understøtter QUIC.
Hvordan kan man stoppe brugen af QUIC
I længden vil jeg ikke mene at man bør stoppe brugen af QUIC.
Udviklingen af og brugen af QUIC er der simpelhen for mange fordele
i. Dog vil jeg mene at det
pt ville være det fornuftige at gøre, såfremt man ikke har nogen
systemer der kan fortolke QUIC på nogen måder. Jeg kender faktisk
kun til 2 producenter der kan. 1 i DK og 1 i US.
Løsningen skal nok findes i de løsninger der kan køre Zeek. RIGTIG meget netværks udstyr som de fleste bruger i
dag, bruger ikke Zeek, eller har noget andet indbygget der kan
fortolke QUIC. Dog skal der tilføjes lidt scripts før Zeek kan se og
fortolke QUIC og de informationer man kan få ud af det. Så bare at
have Zeek betyder ikke man default så fortolker QUIC.
At stoppe QUIC i et netværk er simplet.
Drop UDP pakker på port 443. Der kun QUIC jeg kender til der
ligger der og hvad der ellers er endten fejlkonfigureret eller
Trojan trafik) Så man kan roligt gøre det efter min mening og jeg
gør det selv. Dog skal man huske at
browsers også skal ændres såfremt de ikke er dækket af ens eget
netværksudstyr typisk laptops og udstyr der bevæger sig ind og ud af
et netværk.
Hvad er der tilbage
Der er lidt metadata som eks 2 ip adresser der snakker med hianden,
så kan der laves Bit udregninger der siger lidt om hvor meget data
der flyver igennem forbindelsen. Lidt hvor man kan afgøre on det så
er en ondsindet IP. Måske lidt MAC adresser i nogen sjældende
tilfælde. Men typisk giver MAC adressen kun identifikation om de 2
enheder der sidst rørte forbindelsen som en Switch eller firewalls
som er sjældent brugbart til noget stort.
Måske i fremtiden
Source Connection ID's og Destination Connection ID's i QUIC EITF
data pakken. Kunne man tror er valide i en del tilfælde, men de kan
skifte midt i en forbindelse og så stadig være en del af den samme
forbindelse. Her kan man også lave IDS regler der vil trigger, men
jeg ved endu ikke hvor lang tid de typipsk lever og om det ville
give noget der kan arbejdes med i længden, tror det kommer lidt an
på selve implementeringen. Typisk ville de kun kunne blive benyttet
hvis man er Google eller den der ejer serveren der levere content.
Lige nu er de fleste bare helt blinde.
SANS Whitepaper fra 2020
SANS har lavet en god test af QUIC som er fra 2020. Jeg vil anbefale man
læser den igennem, for det er helt sikkert tid til at skifte netværk
overvågnings udstyr ud med noget der kan fortolke QUIC.
QUIC & The Dead: Which of the Most Common IDS/IPS Tools Can Best
Identify QUIC Traffic
QUIC- A Quick Study
Udgivet fra Santa Clara University skrevet af Puneet Kumar Denne
er også fra 2020 og giver en lidt anden vinkel end SANS. Men
informationen er god.
The TCP killer
Chris Greer har på
Sharkfest 2021 lavet en youtube video jeg desuden kan anbefale
man ser igennem.
Bemærk lige hans kommentar om at Microsoft planlægger at omlægge SMB
trafik til QUIC.
Den er der faktisk allerede en del hold i. Desuden ved jeg at
mange IoT producenter arbejder på at implementerer QUIC da der er
store fordele i dette for dem også.
QUIC Standarden
Man kan
læse mere om selve standarden her -
https://datatracker.ietf.org/doc/rfc9000/
Wireshark profil
Jeg har frigivet en
Wireshark profil
der er lavet til at analysere QUIC, man med fordel kan benytte i sin
egen Wireshark for at komme hurtigt i gang.
IDS rule frigivet
Kigger på versions nummeret i protokollen. Det er tæt på det eneste
der validt kan detectes for. Der findes ikke nogen parser som eks i
Wireshark der kan kigge efter domæne / server navne osv i SNORT
eller Suricata. Parseren i Wireshark virker også lidt underlig ind
imellem, hvor jeg ikke helt kan genneskue hvad der foregår.
Rule ID sid:5003062 - (Disabled som default i mit IDS Rule set) Jeg
ville nok selv enable denne IDS rule, kun for at foretage en valid
søgning efter antallet af oprettet forbindelser til domæner. Det kan
derved countes og giver et overblik over hvor meget der er af QUIC
trafik.
alert udp $HOME_NET 1024: -> $EXTERNAL_NET 443 (msg:"NF - QUIC
version 1 - Detected"; content:"|00 00 00 01|"; offset:35; depth:45;
reference:url,networkforensic.dk; classtype:unknown;
metadata:01102021; sid:5003062; rev:1;)
Quic happy hunting.....
Remcos-RAT
26 September 2021 - Blog Post # 801
Remcos-RAT
Tilbage i September 2019 skrev jeg om Remcos-RAT som jeg
dengang syntes var en rigtig "godt lavet" RAT. Det syntes jeg
stadig, dog er den lige blevet et hak bedre. Der er stort set ikke
meget tilbage i tafikken hvorpå denne kan identificeres på andet end
et par unormale porte med TLS Client Helo i. Bliver denne brugt
henover de normal TLS port ville denne stort set være "umulig" at
finde. Det sample jeg lige har undersøgt at Remcos er brugt i et
målrettet angreb hvor payloads indeholder exploits med bla Microsoft
Office Memory Corruption mm.
IDS Rule Frigivet
Denne finder faktisk kun TLS Client Helo på de "unormale" porte. Dog
skal man lige være vågen for der er ikke noget certifikat at finde i
trakikken. Jeg vil tro denne IDS rule kan give falske positiver, men
bør være meget begrænset i omfang. Derfor bør man holde øje med de
IDS rules der trigger imod den pågældende host da der typisk er
andet at finde samtidigt.
Trojan Squirrelwaffle Loader
25 September 2021 - Blog Post # 800
Squirrelwaffle
Loader
Squirrelwaffle loader er åbenbart det der har overtaget den
"gamle" Qakbot Botnet infrastruktur. Så vi skal nok vænne os til at
se mere til Squirrelwaffle. Den 13 September 2021 gik det løs med
distribution af Cobolt Strike med hjælp fra Squirrelwaffle loader.
Det køre lige nu som mails med links fra en dokument fil, der pakker
en vbs fil ud som henter "forskellige" payloads. Lige nu er det
Cobolt strike.
C2 domæner
Der findes masser af domæner med C2 der allerede er blokeret. Det
her er bare et udsnit af dem der findes. Men man kan med fordel
blokere for disse.
centralfloridaasphalt[.]com
kmslogistik[.]com
chaturanga[.]groopy[.]com
mercyfoundationcio[.]org
shoeclearanceoutlet[.]co[.]uk
spiritofprespa[.]com
jhehosting[.]com
key4net[.]com
lead[.]jhinfotech[.]co
voip[.]voipcallhub[.]com
voipcallhub[.]com
bartek-lenart[.]pl
lenartsa[.]webd[.]pro
amjsys[.]com
novamarketing[.]com[.]pk
ems[.]prodigygroupindia[.]com
hrms[.]prodigygroupindia[.]com
SRP Rule
Det er nok tid til at tilføje følgende sti til sine SRP rules. Det
breaker alle kampanger der er set indtil nu.
Tilføj "vbs" til "Designated file
type Properties"
Tilføj %PROGRAMDATA%\ til Path
Rules som disallowed
Kendte triggers på stribe
Det er ikke fordi man slet ikke kan opdage de her kampanger med de
default triggers der allerede findes og dem jeg selv har lavet
bliver da også triggert på stribe.
IDS Rule
Frigivet
Lidt sjovt, at jeg denne gang skulle lave en IDS rule, på det der
faktisk ikke lige
er synligt i en Wireshark forensic analyse af trafikken. Men den
fanger alle de kampanger der er set indtil nu og finder C2 trafikken
med det samme også fra alle de ikke kendte domæner. Ingen kendte
falske positiver.
Security.txt
15 September 2021 - Blog Post # 799
Security.txt
Igennem mange år hvor jeg har arbejdet med IT-Sikkerhed,
kan jeg simpelhen ikke længer huske hvor mange gange jeg har opgivet
på få kontakt med forskellige virksomheder, fordi jeg har fundet
sårbarheder, malware, de har været hacket osv osv. Jeg har opgivet
at få kontakt og nogen gange efterfølgende set i medier at de netop
er blevet hacket, det er lidt en aha oplevelse må man sige. Her må
man bare trække på skulderen og og tænke på hvordan det kunne have
set ud for dem, hvis der bare lige var lidt kontakt information til
de rigtige personer.
Virksomheder
Mange virksomheder opgiver simpelthen ikke nogen information eller
vej ind til at få den nødvendige kontakt. Som jeg ser det, har dette
altid været et STORT problem. Efter man så fjernede de få muligheder
man havede med GDPR lovgivning, som man i nogen tilfælde kunne fnde
eks via DK-Hostmaster, så blev det bare endnu værre.
ietf.org - RFC
draft
Det nye tiltag jeg har set for nylig under IEFT vil jeg meget
gerne støtte op omkring, da det gør det muligt rent faktisk at
advare andre under en sæt regler der er deffineret i RFC standarden.
Det handler især omkring hvordan man kan opsætte de nødvendige
informationer så det bliver muligt at få kontakt til virksomheder.
Der er sågar oprettet online
framework der
kan støtte den enkelte virksomhed i at få gjort det rigtigt fra
starten.
Jeg har selv oprettet en
security.txt fil her under mit eget web-site, man kan bruge som
inspiration til sin egen virksomhed. Her har jeg også lænt mig lidt
op af hvad andre allerede har gjort på området. Jeg ved der er et
par fodfejl i det jeg har gjort i forhold til standarden. Det er
lige nu helt med vilje, men det virker. Jeg har sågar valgt at
publicere et link under contact som kan benyttes. Det behøver ikke
være så hemmeligt for min skyld.
Opfordring
Det er min helt klare opfordring at virksomheder bør opsætter disse.
Hvem vil ikke gerne blive advaret i tide. Det er stort set gratis.
Jeg køber virkelig ind på dette og kan anbefale andre at gøre det
samme.
Jeg vil også gerne lige takke
Kristian Bodeholt for at gøre mig opmærksom på dette framework.
Udløbet certifikater "Kerio" eller GFI Software
23 August 2021 - Blog Post # 798
Kerio idag GFI
Software
Vi lever altså i nogen tider hvor man efterhånden er blevet
dygtige til at holde øje med om et Certifikat er udløbet.
Det kan man dog ikke sige om Kerio efter de for en del tid siden
blev købt af GFI
Software
Udløbet certifikater.
Jeg har i efterhånden en del tid prøvet at gøre dem opmærksomme på
at deres certifikater er udløbet helt tilbage i til 28 januar 2021.
Jeg har udfyldt en del support sager til dem, og ingen ting sker
der.
Det er typisk sådan at hvis man først udadtil viser at man ikke helt
har styr på det og det ligner lidt en roddebutik, så plejer det at
afspejle at det faktisk er mere slemt på indersiden af et netværk,
derfor skal man bla også vise at man ikke benytter udløbet
certifikater osv osv..og slet ikke hvis man påstår man er en
sikkerheds virksomhed, det gir altså slet ikke noget plus i bogen
heller ikke selvom man er ved at udfase en produkt.
Det har ikke været super godt for de gamle Kerio produkter at de er
kommet ind under GFI software. MEN jeg er ret overbevist om at de er
ved at gå "software
døden" lidt i møde. jeg vil nok ikke anbefale nogen at kaste
penge efter kerio produkter mere. Det virker lidt som om det bare er
ved at vride citroen for de sidste dråber.
rclone detection with Sysmon
17 August 2021 - Blog Post # 797
rclone
rclone er gået hen og blevet en ting som en del ransomware
bla benytter til at foretage x-fil af data til cloud providers. Mere
information her -
https://research.nccgroup.com/2021/05/27/detecting-rclone-an-effective-tool-for-exfiltration/
Man bør holde øje med hvor i ens infrastruktur rclone benyttes.
Lagt ind i Sysmon config fil
For at bedre kunne opdage når rclone bliver installeret (oprettet)
er dette nu lagt ind i min sysmonconfig.xml fil.
Det vil blive opdaget via Security Onion i Kibana som
technique_id=T1020,technique_name=rclone
‘PrintNightmare’ - CVE-2021-1675
4 Juli 2021 - Blog Post # 796
Sårbarhed i
print spooler servicen
Ja endnu en sårbarhed i en Microsoft Service. Netop print
spooler servicen har der igennem tiden været flere kritisk
sårbarheder til. Derfor helt tilbage fra Windows XP tiden har det
været god skik ikke at starte denne service som default på andet end
print servers. NEJ en AD controller skal ikke være print server.
Klienter skal heller ikke agere print servers. Heller ikke selvom
Microsoft syntes det er en god ide at service er startet som
default.
Fiks fra Microsoft bliver frigivet 12 Juli 2021 til dette.
Man skal ikke gå i panik over denne selvom rigtig mange gerne ser
man gør. Hvem kan ikke leve uden en ny printer bliver installeret
før den 13 Juli 2021 (7 dage fra nu)
Skift rettigheder på følgende
C:\Windows\System32\spool\drivers (med alle subfolders) "Deny
modify" Fjerne også system rettigheder. Det forhindre også den POC
der er i omløb slet ikke vil virke.
Det der allerede er installeret vil stadig virke med denne simple
mitigering: Selvom nogen siger det er en dårlig ide så virker det
rigtig fint at ændre rettigheder på folderen og det kan gøres indtil
et pacth er kommet. Inden du patcher skal du selvfølgelig huske at
ændre rettigheder tilbage igen.
Det er jo ikke sådan at alle printere holder op med at virke og husk
driveren er installeret på print serveren. Endnu mere vigtigt er at
et print job bliver sendt til følgende sti på en print server -
C:\Windows\System32\spool\PRINTERS
(Hvis det er Windows) og det er ikke den der er ændret rettigheder
på. Så print virker stadigvæk. Min overbevisning siger mig at 99.99%
af forretningen virker indtil en patch er kommet. Og du kan nu sove
roligt de næste 7 dage. Husk det er en mitigering ikke en permanent
fiks.
Nogen påstår det er den vildete sårbarhed i 17 år.
Til det kan jeg kun sige sikken en gang vås. Jeg kan uden problemer
finde hunderedvis i samme kategori bare fra 2020. Noget bliver ikke
mere sårbart end CVSS v3.0 Rating10.0. En sårbarhed kan være kritisk
på mange måder. Giver den system rettigehder, så er den lige så slem
som alle de andre med CVSS 10.0. Kan den bruges af orme osv så er
det jo skidt. Igennem 2020 har der være flere sårbarheder der kan
bruges af orme. Så det gør ikke denne her til noget mere spicelt end
alt det andet der har været.
Lige netop print spooler. Der skal man i 99.9% af alle tilfælde have
adgang til der hvor der er en print server eller som nogen uheldige
elementer har gjort det og installeret print serveren på en AD
controller. Det er typisk på et LAN.
Jeg kan virkelig anbefale at bruge Linux (Ubuntu) som print servers,
såfremt man har brug for print servers.
Til mange vil det nok være en god ide at få kigget generalt på print
spooler servicen i et Microsoft setup. Få den nu kun aktiv der hvor
den skal bruges (på print servers) og Linux Ubuntu servers virker
fint som print servers. Vi ved jo det er en service på Microsoft der
har været i target mange gange før, så hvorfor ikke bruge en Linux
kasse når nu servicen alligevel skal være tilgængelig for mange. Så
kan man også spare den licens.
Følgende GPO kan bruges
Allow Print spoolers to accept client connections - set to disabled
Yderligere kan man nøjes med at disable Print Spooler
servicen
Print Spooler - startup type = disabled
Security Onion med Sysmon
Bruger man Security onion eller bare Sysmon og opsamler disse til en
ELK med winlogbeat, kan jeg anbefale følgende:
I min frigivet Sysmon config er den nu tilpasset så man ser alle
filer der bliver oprettet i
C:\Windows\System32\spool\drivers og underforlders.
Følgende søge strenge kan benyttes til at finde oprettet filer i
denne folder:
Elk søgning: target_filename:
"c:\\Windows\\System32\\spool\\drivers\\*"
Evt kig efter rulename:
Bruger man ikke det at ændre rettigheder og i stedet vil holde øje
med hvor mange filer der bliver oprettet i en instastruktur i
drivers folderen med sysmon. Så vil man nok blive lidt forbavset
over hvor lidt der sker dernede.
event_data.RuleName: "File created in
Print Drivers folder"
Til sysmon config:
<RuleGroup name="" groupRelation="or">
<!-- Event ID 11 == FileCreate. -->
<FileCreate onmatch="include">
<TargetFilename name="File created in Print Drivers folder"
condition="begin
with">C:\Windows\System32\spool\drivers</TargetFilename>
Security.ipip.net - Endnu en uautoriseret scanner
14 Maj 2021 - Blog Post # 795
Uautoriseret
scanner
Security.ipip.net er blot en mere på listen over nogen der
mener, de har ret til at footprinte hele internettet, inklusiv de
sårbarheder som de så kan finde. Man ved ikke hvad data går til. For
mig er dette altid kun en target liste og ligger i
kategorien "Recon"
Det er lidt underholde at se hvad de mener de har RET til.
(Ping / Traceroute Mainly) Hvad betyder Mainly i denne sammenhæng ?
Jeg kan så bekræfte at det er det langt fra. Jeg kan finde dem på
rigtig meget andet end det.
Deres IP adresser.
Jeg har brugt lidt tid på lige at lede lidt mere efter dem. De
benytter primært linode IP ranges. Man kan for nemhedens skyld bare
blokke hele linode. Men jeg har frigivet
den konkrete IP liste her, så man selv kan lave Firewall rules
mm.
IDS Rule frigivet
Jeg har firigivet IDS rules således man selv kan få et overblik over
hvor meget man bliver scannet af dem.
Emotet takedown lader til at virke
26 April Februar 2021 - Blog Post # 794
Nedtagning af Emotet virker
Skrev i blogpost 790 om Emotet nedtagningen som er foretaget af
Europol Cyber Defence. Det lader til at Europol Cyber Defence har
gjort et fint stykke arbejde. Den sidste del, hvor Emotet ville
afinstallere sig selv d 25 April 2021 lader til at virke. Der er
ifølge Any.Run's meget fine tracker system ikke set nye sampels
efter 25 April.
Vi siger tak herfra til Europol Cyber Defence
Nogen fik ret og andre gjorde ikke og så er der dem der har fjernet
deres blogopslag hvor de "hakker" lidt på Europol Cyber Defence og
påstår det ikke vil virke. Har de mon fjernet deres opslag fordi de
er flove ?
Elendige dårlige phishing scammers
09 April Februar 2021 - Blog Post # 793
Forsøg på misbrug i forbindelse med
Corona, pas, e-boks, Nemid og Postnord osv.
Hvor dårlig kan man blive til phishing kampanger ? Det er helt vildt
så dårligt udført det her er.
Stoppede en phishing mail, der vil se ud som den kom fra e-boks, men
oplysninger viser postnord og payload skal hentes på
billingpostnord[.]com. Det er en stor rodebutik, men det matcher med
de mange andre daglige kampanger der er målrettet danskere for tiden
med PostNord tema.
Postnord phishing kampanger imod alle
Igennem det seneste lange stykke tid har jeg dagligt set phishing
mails sendt imod danske virksomheder og private og lige netop
PostNord temaet er ret omfattende misbrugt. Men jeg ser også mange
ligheder imellem fejl der i disse kampanger og hvor den "person" der
sidder og opfinder de domæner der benyttes i disse kampanger,
simpelthen er så dårllig til at finde på nye navne at ligheden
imellem 90% af dem er i samme udformning.
Lige netop denne kampange har samme karakteristika som jeg har set
tidligerer. Det er jo helt vildt skrald at benytte tema fra
tidligere eller kommende postnord kampanger til at forsøge at
misbruge bruge e-boks. Hvem vil lige uploade billeder af sit PAS til
nogen som helst.
Opfordring til NC3 (Politiet)
Jeg vil rigtigt gerne komme med en venlig opfordring til NC3
(Politiet) til at begynde at lave noget efterforskning denne
gang. For en gang skyld på noget der kan beskytte mange danskerer og
virksomheder, da der rent faktisk er noget at gå efter i de mange
phishing mails med postnord tema. De sammen benytter iøvrigt Nemid
tema også.
Jeg er ret overbevist om at det er den/de samme personer, der står
bag de fleste af disse kampanger. Det vil være med til at få lukket
ned for de mange daglige angreb, vi ser imod danskerer og danske
virksomheder.
Opfordring til Postnord
Noget andet jeg har bemærket i forbindelse med Postnord, er at når
man snakker med folk eller bare selv bestiller en vare hvor Postnord
skal leverer pakken, så vil man endten samtidigt eller inden for
minutter/timer efter bestillingen også modtage den første phishing
mail med Postnord tema. Det kunne være værd for postnord på den
observation lige at få gennemgået egne servers, for jeg er ret
overbevist om at "nogen" følger med i hvornår der sendes valide
mails ud. Det er ikke et tilfælde, der er for meget røg.
Anbefaling til beskyttelse imod disse Phishing mails
Vær opmærksom på at postnord kun sender mail fra følgelde mail
adresser
de har selv beskrevet her.
Samme type information bør andre statslige institutioner oplyse om.
Det kan hjælpe i kampen imod Phishing.
Whitelist følgende afsenderer:
noreply@postnord.dk
noreply@postdanmark.dk
Blacklist følgende afsendere eller replay to
noreply@postnord.com
no-reply@postnord.com
OBS - Nogen virksomheder bruger følgende URL når de sender besked
til brugerne med et tracking nummer. Dette kan findes i content i
mailbody. I disse tilfælde er mailen typisk valid. Til dem der
sender mails ud fra deres web-shop burde droppe det. Man er nød til
at lave undtagelser på anden vis her. Kommer lidt an på hvilket
system man benytter til SPAM håndtering.
https://tracking.postnord.com*
Yderligere kan man tilføje følgende SPAM regler til SPAM
håndteringen i content.
Søg efter content i mailbody. Sørg for at whitelist filteret på de
valide afsender adresser kommer før content regler.
https://*postnord.blogspot.com/
https://*postnord.com/
https://*postnord*.com/
https://postnord*.com/
https://www.*.com/.postNord.dk/
https://postnord*.online/
Happy Hunting.......
Binaryedge ninja
20 Februar 2021 - Blog Post # 792
Binaryedge
Bare endnu et
skod firma der syntes de skal scanne internettet. Jeg kan kun
anbefale at man går imod denne type virksomhed og lige tænker over
sin egen dobbeltmoral, inden man syntes man vil tilkøbe data fra
nogen der skider højt og flot på andres sikkerhed og leverer
"attack" data til andre. Jeg ser mange der køber data fra denne type
data brokers inklusiv de danske myndigheder.
Research
Jeg går meget ind for research af sikkerhed. MEN det skal gøres på
den rigtige måde, hvis det skal gøres ellers er man ikke bedre end
ondsindet hackers og meget andet skrammel, der er med til at gøre
Internettet til et usikkert sted at være. HUSK når data bliver
indsamlet, så kan det i høj grad også bruges ondsindet eller til
egen fordel på mange måder.
Der er en udbredt misopfattelse herunder hos danske CSIS om man bare
kan bruge de data der er indsamlet på den mindre pæne måde. Man skal
tænke over hvilket indtryk omkring moral og etik man vil sprede
udadtil når man bruger data. Herunder hvordan en IT-Sikkerheds
virksomhed skal fremstå. Det CSIS præsentere er nok en dårlig moral
på nogen områder.
Man fremstår IKKE moralsk og etisk rigtig, ved at ride med på bølger
i medier mm for at kunne lave ambulance artikler om hvor usikre
andre er, bare for at kunne lave et mersalg. Det er den genralle
ting man ser mange virksomheder der har noget med IT-Sikkerhed gøre.
Jeg har også selv været på den vogn og er blevet klogerer.
Man sætter man sig selv i bås og jeg er ret overbevist om at moral
og etik især fra IT-Sikkerhds virksomheder står højt på manges liste
når de vil vælge hvem der skal lave sikkerhed for dem. Som Peter
Kruse siger, så har det været alm praksis i mere end 10 år. MEN det
gør det ikke mere rigtigt. Fordi alle køre over for rødt lys er det
bare ikke rigtigt at følge med ? Lagt fra. Nu nævner han selv SHODAN
og lige netop dem har jeg skrevet mange artikler om, og hvad
risikoen er ved at lade sig scanne blidt af dem. For de er netop i
høj grad med til at gøre Internettet et usikkert sted at være.
Til de sikkerheds folk der arbejder i en type af virkksomhed der
måske har en lidt dårlig moral, her skal man selv tænke over om den
moral som virksomheden præsenterer, er en man gerne selv vil have
siddende på sit CV, såfremt man vil ud og gøre karriere senere hen.
For det spiller en stor rolle.
Husk research er fantastik, men gør ikke andre andre usikre eller
bring dem i en situation hvor det kan gå helt galt for dem. Gør det
ansvarsfuldt så dem der bliver usikre i forbindelse med din
research, altid har en chance for at bringe ting i orden. Vil du
scanne hele internettet efter det du har fundet, så gør det selv.
Men giv andre en mulighed for at vide hvem det er der scanner. Lige
så snart du bruger andres data og platforme, så er der rent faktisk
andre der følger med i hvad du leder efter. Så kan dine fund rent
faktisk misbruges af andre med mindre pæne hensigter.
Husk din research skal være med til at hjælpe andre.....Arbejder du set sted hvor det ikke er tilfældet, så tænk over den moral og etik du selv vil være sat i forbindelse med. For dem der skal ansætte dig senere, vil kigge på hvor du kommer fra.
TOR-Browser v10.x
13 Februar 2021 - Blog Post # 791
TOR-Browser
På opfordring har jeg opdateret IDS rules til at finde klienter der
benytter sig af TOR-Browsers. De gamle IDS rules jeg har (nu
disabled) virkede kun imod 8.x versioner, men er blevet for gamle.
Det er også lang tid siden jeg har brugt mere end 2 timer på at få
fremstille en IDS rule der virker. Der er stor forskel på om noget
virker på en windows installeret SNORT eller om det er til Security
Onion. Mine IDS rules skal helst virke begge steder. Det var lidt en
udfordring denne gang. Men det virker nu......
Security Onion - JA3
I forhold til TOR-Browsers, så har det hele tiden virket med
detection på JA3 Hash'en alene. Denne er ikke skiftet i TOR i
årevis. Derfor har jeg ikke haft den store fokus på at få dette til
at virke i SNORT. Dette dashboard har været tilgængeligt også i
årevis fra mit download
Security Onion Tool site. Det virker stadig på stort set alle
versioner af TOR også den nyeste version.
IDS rule frigivet
Jeg har frigivet den nyest IDS rule til at finde Tor-browseres der
køre 10.x. De gamle IDS rules omkring TOR er nu disabled i IDS
sættet. Den kan muligvis give falske positiver, i så fald høre jeg
gerne om det og gerne med en tilsendt pcap fil, ellers er det svært
at tilrette. Jeg ved der kan være et problem med nogle spicelle
certifikater fra Google, men det er heldigvis meget få. Men jeg har
endu ikke kunne finde et certifikat der giver denne falske positiv.
Emotet takedown - Virker det ?
8 Februar 2021 - Blog Post # 790
Emotet takedown - Virker det
I forbindelse med
Emotet takedown er der "nogen" derude der siger det ikke vil
have nogen effekt. Har de nu også ret i hvad de påstår ?
Nye samples
Der triller stadig nye sampels ind hver dag på Emotet. Men dette kan
sagtens være rester at en automatiseret infrastruktur, der stadig
står og sender kampanger ud. Men umiddelbart kan man jo godt give
dem ret i at det ikke har den ønskede effekt. Men tænker man tilbage
SQL Slammer fra 2003, så dukkker den også stadig op derude ind
imellem. Jeg vil næste tro at det bliver det samme med Emotet, da
der sikkert er mange inficeret hosts derude.
Hvordan ser det overordnet ud
Kigger man på de forskellige watches der findes på internettet, der
holder øje med de forskellige malware kampanger. Så ser alle sammen
næsten ens ud. Det har en stor indvirkning på Emotet, som næsten
droppede til ingenting sammenlignet med tidligere. Men nu ser
desværre en lille stigning igen, så måske de
får ret alligevel.
Følger med
Over den næste lange tid vil jeg da også holde et våget øje med
Emotet, for det er noget jeg selv har brugt meget tid på at overvåge
og lave detection for samt tømt enkelte af deres dropsites. Den store dato bliver 25 April 2021 som
er der hvor myndigheder har sat Emotet til at afinstallere sig selv.
Efter denne dato bliver det især vigtigt at holde øje med det. Jeg
håber det forsvinder for der er så meget andet at holde øje med
derude.
Dog er det mig helt uforståligt at man har meldt denne dato ud. Det
virker næsten som om man har givet nogen en chance for at rykke sig
til ny infrastruktur. De burde bare have holdt dette hemmeligt.
JARM fingerprinting Cobolt Strike servers
23 January 2021 - Blog Post # 789
JARM
Salesforce har frigivet en metode til at fingerprinte TLS
servers de kalder for JARM. Dette gør det muligt meget præcist at
fingerprinte eks malicious servers som kunne være Command and
Control Servers. Det er virkelig "top of the art" i jagten på at
identificere skidte ting på internetet når man først har fået færten
af dem. Det minder på overfladen lidt om JA3 som Salesforce også kom
med. JA3 er passiv og JARM er dog aktiv scanning. Jeg 100% sikkert overbevist om at netværks relateret
sikkerheds løsninger der i dag ikke kan JA3 eller JA3S skal man slet
ikke spilde sin tid eller penge på.
Cobolt Strike
Cobolt
Strike er et ret avanceret pentest tool. Det koster kassen, men
bruges af rigtig mange sikkerheds virksomheder der fortager
pen-test. Dog er der over den seneste tid set et meget stort skifte
i at dette også bruges af kriminelle grupper til Ransomware attacks,
BotNets, og ikke mindste i det seneste "Solarwinds attack"
hvor man tog noget der minder om en Ferrie af et stykke malware i
udførelse og metodik for til sidst at lave det om til en klovnebil
hvor man brugte Cobolt Strike i sidste ende som final payload.
Cobolt strike for fun and profit
Alt efter hvordan man ser på dette, så er det helt klart i min optik at man altid kan vende sig til endpointet for at se hvad der sker og hvem der lavede en forbindelse til en JARM identificere hash. Det er helt klart min holdning at man i 99.9% af alle tilfælde altid vil finde noget der ikke burde ske. Så nej JARM er ikke 100% sikker alene, man skal kunne validere hvad der sker på endpoints samtidigt, så gir det altid 100% mening.
Der er
frigivet en liste med hvad der allerede nu er identificeret som Cobolt Strike Beacons. Jeg har lave en liste med IP adresser virksomheder kan smide direkte ind i en deny drop liste. Det anbefaler jeg nok man får gjort. DOG er jeg ret overbevist om det sikkert ikke er alle Cobolt Strike Beacons der er blevet identificeret, men det er et stort skridt på vejen...Håber dog på vi snart ser JARM i nmap hvilket kunne være en rigtig god ting.Cobolt strike for fun and profit
Alt efter hvordan man ser på dette, så er det helt klart i min optik at man altid kan vende sig til endpointet for at se hvad der sker og hvem der lavede en forbindelse til en JARM identificere hash. Det er helt klart min holdning at man i 99.9% af alle tilfælde altid vil finde noget der ikke burde ske. Så nej JARM er ikke 100% sikker alene, man skal kunne validere hvad der sker på endpoints samtidigt, så gir det altid 100% mening.
Der er
frigivet en liste med hvad der allerede nu er identificeret som Cobolt Strike Beacons. Jeg har lave en liste med IP adresser virksomheder kan smide direkte ind i en deny drop liste. Det anbefaler jeg nok man får gjort. DOG er jeg ret overbevist om det sikkert ikke er alle Cobolt Strike Beacons der er blevet identificeret, men det er et stort skridt på vejen...Håber dog på vi snart ser JARM i nmap hvilket kunne være en rigtig god ting.
Nugget Phantom
10 January 2021 - Blog Post # 788
Nugget Phantom
Faldt over noget Nugget Phantom malware, der lige nu er i gang i
stor stil via malware kampanger. Det er nok en god ide at være vågen
overfor dette malware, da noget har kastet deres kærlighed på det.
Det bliver lige nu spredt med PurpleFOX EK. De forskellige malware
sanbox løsninger derude er fyldt med det . Eks
Any run har en del liggende.
Nugget Phantom larmer en del på inficeret maskiner, da det starter eks port scanninger på port 445 efter EternalBlue. Nugget Phantom er et ægte modularized malware toolkit.
IDS detection
Har frigivet generic IDS rules der også burde kunne fange nuværende
og kommende
kampanger. Det siger jeg ud fra at have analyseret en del kampanger
og kun lave IDS rules på det der plejer at skifte. Det kan jo godt
skifte alligevel, men har ikke gjort det siden 2016.
Update my SMB profile for Wireshark
02 January 2021 - Blog Post # 787
SMB profiles
SMB profilen bringer mange af de ting til live i Wireshark som man
normal skal bruge meget tid på at lede efter. Ved at filters
allerede er lavet spare man derved meget tid i sin analyse. SMB er
nok en af de mest kompliceret protokoller når man snakker analyse i
Wireshark. Denne hjælper tit mig en hel del.
Blog posts
Alt hvad jeg har skrevet om igennem 2021